2026-06-23-12-07-35 部署并验证局域网 4000 服务

工程分析/经验记录.md

@@ -2013,3 +2013,21 @@ C. 解决问题方案
 D. 后续如何避免问题
 
 后续做局域网部署时，部署验证必须同时覆盖三点：目标 IP 是否属于当前机器、端口是否监听在 `0.0.0.0`、目标 IP 的 API 和首页是否都能访问。若没有既有 tmux 会话，可直接创建同名会话；若端口被占用，则先记录占用来源再处理。
+
+## 2026-06-23-12-07-35 无源码变更部署仍要记录实际运行命令
+
+A. 具体问题
+
+用户要求阅读整个工作区并部署到 `http://192.168.3.11:4000/`。本次没有业务源码变更，但仍需要完成构建、长期运行托管、局域网访问验证和文档备份提交。
+
+B. 产生问题原因
+
+部署类需求会改变运行态服务，即使不改源码也可能受端口占用、`tmux` 会话残留、网卡地址、生产/开发服务模式和前端入口访问影响。如果只记录“服务已启动”，后续排查时无法确认实际运行命令和验证覆盖面。
+
+C. 解决问题方案
+
+按工作流创建本次需求分析、实现方案和测试方案。执行前再次阅读部署相关经验，确认 `192.168.3.11` 属于本机网卡且 `4000` 端口空闲。通过 `npm run lint`、`npm run build` 后，在 `tmux` 会话 `revoxelseg-dicom` 中使用 `NODE_ENV=production npm run serve -- --host 0.0.0.0 --port 4000` 启动服务，并分别验证 `127.0.0.1` 与 `192.168.3.11` 的 `/api/health` 和首页均返回 HTTP 200。
+
+D. 后续如何避免问题
+
+后续无源码变更的重新部署也要记录实际启动命令、运行载体、端口监听地址、目标 IP 归属以及 API/首页双验证结果。若使用 `npm run build` 后部署，优先记录是否以 `NODE_ENV=production` 服务 `dist/`，避免开发中间件 Host 校验或源码热更新状态影响访问判断。