2026-05-21-16-34-09 暂停当前系统服务

工程分析/经验记录.md

@@ -1585,3 +1585,21 @@ C. 解决问题方案
 D. 后续如何避免问题
 
 后续生成配音、字幕或二次包装视频时，不能只看 MP4 容器总时长；必须同时检查视频流和音频流时长。若目标是避免片尾空声，应以视频流时长为准；若目标是保留完整旁白，则需要明确允许画面补帧或拉伸。大幅时长差不要依赖静音填充，应优先调整文案长度和 TTS 语速，再做细微 `atempo` 对齐。
+
+## 2026-05-21-16-34-09 暂停服务时不应再执行重新部署
+
+A. 具体问题
+
+用户要求“停一下现在的系统”，目标是暂停当前服务，而项目工作流默认在修改完成后要求重新部署。如果机械执行重新部署，会违背用户本次意图，让系统又重新对外提供访问。
+
+B. 产生问题原因
+
+项目工作流面向常规功能修改和部署更新，默认以“修改后恢复服务”为完成标准；但本次属于运行态暂停操作，验收标准恰好相反，需要确认 Docker 容器停止、`4000` 端口释放、健康接口不可访问。
+
+C. 解决问题方案
+
+先检查当前运行来源，确认服务来自 `/home/wkmgc/Desktop/ReVoxelSeg_DICOM_Docker` 的独立 Docker Compose，而不是 `tmux`。随后执行 `docker compose -f docker_compose.yaml down`，同时停止 web 与 frpc 容器。停止后验证 Compose 服务为空、`4000` 端口无监听、本机健康接口连接失败、公网域名返回后端不可达状态。本次在工程分析中明确记录“不重新部署”是按用户要求执行。
+
+D. 后续如何避免问题
+
+后续遇到“停止、暂停、下线、关闭服务”类请求时，工作流中的重新部署步骤应解释为“运行态验证”，而不是再次启动服务。最终汇报要明确服务已停、恢复命令是什么，以及哪些入口当前不可访问，避免把暂停请求处理成重启请求。