2026-05-24-09-58-56 恢复Docker部署并清理发布分支

工程分析/实现方案-2026-05-24-09-58-56.md

@@ -0,0 +1,74 @@
+# 实现方案-2026-05-24-09-58-56
+
+## 实现方案文档路径
+
+`工程分析/实现方案-2026-05-24-09-58-56.md`
+
+## 修改目标
+
+- 阅读并梳理当前项目结构、技术栈、运行方式和 Docker 发布历史。
+- 恢复误删的 `Docker部署/` 文件夹。
+- 核查 Gitea 远端分支、tag 与 Release/附件关系；确认发布物仍由 tag/附件承载后，删除四个不再需要的发布辅助分支。
+- 构建并重新部署 `WebSite` 服务，验证本机与公网访问。
+- 完成工程分析记录、经验记录追加、Git/Gitea 备份提交。
+
+## 涉及路径
+
+- `Docker部署/`
+- `工程分析/需求分析-2026-05-24-09-58-56.md`
+- `工程分析/实现方案-2026-05-24-09-58-56.md`
+- `工程分析/测试方案-2026-05-24-09-58-56.md`
+- `工程分析/经验记录.md`
+- `WebSite/`
+
+## 技术路线
+
+1. 使用 `git status`、`README.md`、`WebSite/package.json`、历史工程分析文档了解项目现状。
+2. 通过 Git 历史或远端 `main` 恢复 `Docker部署/`，再核对恢复文件内容。
+3. 使用 `git ls-remote` 与 Gitea API 检查远端分支、tag、Release 和附件；发布项和附件确认存在后，删除仅用于固化发布配置的辅助分支。
+4. 执行 `npm run build` 验证前端生产构建。
+5. 使用 `tmux` 会话 `revoxelseg-dicom` 启动 `npm run serve -- --host 0.0.0.0 --port 4000`。
+6. 用健康接口、首页和公网域名做部署验证。
+7. 追加经验记录，暂存本次相关文件并提交，推送到 Gitea。
+
+## 执行步骤
+
+1. 记录开始时间并阅读 `代码编纂工作流.md`、`工程整体分析.md`、`经验记录.md`。
+2. 创建本次需求分析、实现方案、测试方案文档。
+3. 再次读取 `经验记录.md`，满足执行前确认要求。
+4. 恢复 `Docker部署/` 并检查 `Dockerfile`、`README.md`、本机 Compose、NAS Compose。
+5. 查询远端分支与发布 tag；若 Release 附件存在且 tag 可追溯，删除四个辅助分支。
+6. 执行构建和部署，检查端口与 tmux 会话状态。
+7. 验证 `http://127.0.0.1:4000/api/health`、`http://127.0.0.1:4000/`、`https://revoxel.huijutec.cn/`。
+8. 更新 `工程分析/经验记录.md`。
+9. `git add` 仅暂存本次相关文件，提交并推送到 Gitea。
+10. 最终汇报恢复文件、分支清理、部署验证与 commit 状态。
+
+## 兼容性与回滚方案
+
+- `Docker部署/` 若恢复异常，可从远端 `main` 或历史提交重新取回。
+- 远端分支删除后仍保留 tag、Release 和附件；如确需恢复，可从对应 tag 重新创建分支。
+- 部署失败时保留构建日志和 tmux 输出，必要时回退到此前可用的 Docker Compose 或旧 tmux 会话。
+- 不提交既有无关删除，避免扩大回滚范围。
+
+## 预计文件变更
+
+- 新增三份本次工程分析文档。
+- 恢复 `Docker部署/` 下 4 个文件。
+- 追加 `工程分析/经验记录.md`。
+- `WebSite/dist/` 可能因构建产生本地变化，但不作为本次备份提交重点。
+
+## 提交与部署策略
+
+- 提交信息使用：`2026-05-24-09-58-56 恢复Docker部署并清理发布分支`。
+- 暂存范围限定为本次工程分析文档、经验记录和恢复的 `Docker部署/` 文件。
+- 推送到用户提供的 Gitea 备份仓库对应 `main` 分支。
+- 部署使用 `tmux` 会话 `revoxelseg-dicom` 长期运行 `NODE_ENV=production npm run serve -- --host 0.0.0.0 --port 4000`，避免公网 Host 被 Vite 开发中间件拦截。
+- 公网访问另起 `revoxelseg-dicom-frpc` 容器，使用 host 网络把本机 `127.0.0.1:4000` 映射到 FRP 服务端 `10008`。
+
+## 执行补充记录
+
+- 初次按普通 `npm run serve` 启动后，本机 `/api/health`、`/` 与公网 API 正常，但公网根路径返回 `403 Blocked request. This host ("revoxel.huijutec.cn") is not allowed.`。
+- 原因是非生产模式会进入 Vite 中间件，Vite 对公网 Host 做 allowedHosts 校验。
+- 已改为 `NODE_ENV=production` 启动，服务直接返回 `WebSite/dist/` 生产构建产物。
+- 当前公网链路由 `tmux` Web 服务加独立 `revoxelseg-dicom-frpc` 容器组成。

工程分析/测试方案-2026-05-24-09-58-56.md

@@ -0,0 +1,62 @@
+# 测试方案-2026-05-24-09-58-56
+
+## 测试方案文档路径
+
+`工程分析/测试方案-2026-05-24-09-58-56.md`
+
+## 静态检查
+
+- `git status --short --branch`：确认只暂存本次相关文件，识别并保留既有无关删除状态。
+- `find Docker部署 -maxdepth 3 -type f | sort`：确认 Docker 部署目录恢复完整。
+- `git ls-remote --heads` / `git ls-remote --tags`：确认远端分支、tag 状态。
+
+## 构建检查
+
+- 在 `WebSite/` 执行 `npm run build`。
+- 如时间允许或构建前发现类型风险，执行 `npm run lint`。
+
+## 关键业务场景验证
+
+- 首页访问返回 200，页面包含前端入口。
+- `/api/health` 返回健康状态。
+- 公网页面 `https://revoxel.huijutec.cn/` 返回可访问响应。
+- 若可用，检查首页或登录页关键文本，确认不是代理错误页。
+
+## 医学影像数据相关边界验证
+
+- 本次不修改 DICOM/STL 解析、预览、融合或 Mask 导出逻辑。
+- 部署验证需确保服务仍可扫描默认 `Head_CT_DICOM/` 与 `Head_CT_ReConstruct/` 资源；可通过页面或 API 间接确认项目服务可启动。
+
+## 部署验证
+
+- 检查 `4000` 端口占用与 `tmux` 会话。
+- 启动或重启 `tmux` 会话 `revoxelseg-dicom`。
+- 验证：
+  - `http://127.0.0.1:4000/api/health`
+  - `http://127.0.0.1:4000/`
+  - `https://revoxel.huijutec.cn/`
+
+## Git/Gitea 备份验证
+
+- 本地 commit message 包含 `2026-05-24-09-58-56`。
+- 推送后用 `git ls-remote` 确认远端 `main` 指向新 commit。
+- 删除发布辅助分支后，用 `git ls-remote --heads` 确认四个分支不再存在。
+- 用 tag 或 Release 检查确认发布包仍可追溯。
+
+## 风险与回归关注点
+
+- 避免提交大量已有历史文档删除。
+- 避免删除 Release、tag 或附件。
+- 避免 Docker 与 tmux 同时占用 `4000`。
+- 公网域名如仍异常，需要区分本机服务问题、FRP 问题和反向代理问题。
+
+## 执行结果
+
+- 静态检查：`Docker部署/` 已恢复 4 个文件，包括 `Dockerfile`、`README.md`、本机 Compose、威联通 NAS Compose。
+- 远端检查：Gitea 当前只剩 `main` 分支；`revoxelseg-docker-all-v2026.05.21` Release 仍存在，包含 3 个部署包附件；Docker 发布相关 tag 仍存在。
+- 类型检查：`npm run lint` 通过。
+- 构建检查：`npm run build` 通过，Vite 仅提示 chunk 体积超过 500 kB。
+- 部署检查：`tmux` 会话 `revoxelseg-dicom` 已用生产模式启动，`0.0.0.0:4000` 正常监听。
+- FRP 检查：`revoxelseg-dicom-frpc` 容器日志显示 `login to server success` 和 `start proxy success`。
+- 本机验证：`http://127.0.0.1:4000/api/health` 返回 `ok: true`，`http://127.0.0.1:4000/` 返回 200。
+- 公网验证：`https://revoxel.huijutec.cn/` 返回 200，页面标题为“模型逆向系统”；`/api/health` 返回 `ok: true`；`/api/projects` 可读取默认医学影像项目；登录接口验证成功。

工程分析/经验记录.md

@@ -1621,3 +1621,21 @@ C. 解决问题方案
 D. 后续如何避免问题
 
 后续撰写项目介绍、软著说明、验收材料或宣传文案时，应先核对工程整体分析和最新源码功能，再区分“已实现能力”“演示能力”和“后续预留能力”。涉及医学影像、分割、诊断和算法效果的表述必须保守准确，不能为了文字完整性虚构尚未落地的临床级能力。
+
+## 2026-05-24-09-58-56 Docker 发布分支清理与公网生产模式部署
+
+A. 具体问题
+
+用户误删了主工程 `Docker部署/` 目录，同时 Gitea 中遗留四个 Docker 发布辅助分支。恢复本机 `tmux` 服务后，本机页面和公网 API 正常，但公网根路径一度返回 `403 Blocked request. This host ("revoxel.huijutec.cn") is not allowed.`。
+
+B. 产生问题原因
+
+`Docker部署/` 是已跟踪目录，被工作区删除后可从 Git 历史恢复。四个远端分支只是用于固化 v2026.05.21 Docker 发布包配置，Release 已由 tag 和附件承载，不再需要分支长期保留。公网 403 则是因为普通 `npm run serve` 未设置 `NODE_ENV=production`，服务进入 Vite 开发中间件，Vite 对公网 Host 执行 allowedHosts 拦截；同时公网访问还依赖 frpc 隧道，单独启动 Web 服务不足以恢复域名入口。
+
+C. 解决问题方案
+
+使用 `git restore -- Docker部署` 恢复主工程 Docker 部署文件。确认 Gitea Release `ReVoxelSeg DICOM Docker 部署包 v2026.05.21` 及 3 个附件、相关 tag 均存在后，删除 `docker-standalone-20260521`、`release/docker-machine-20260521`、`release/docker-nas-20260521`、`release/docker-generic-20260521` 四个远端分支。部署时先执行 `npm run lint` 与 `npm run build`，再用 `tmux` 运行 `NODE_ENV=production npm run serve -- --host 0.0.0.0 --port 4000`，并单独启动 host 网络的 `revoxelseg-dicom-frpc` 容器将本机 `127.0.0.1:4000` 映射到 FRP 远端 `10008`。最终验证本机健康接口、首页、公网首页、公网 API、项目数据和登录接口均可用。
+
+D. 后续如何避免问题
+
+清理发布辅助分支前必须先确认对应 Release、tag 和附件均可读，再删除分支而不是删除 tag 或 Release。通过公网域名部署 `npm run serve` 时应使用 `NODE_ENV=production`，否则 Vite 开发中间件可能拦截公网 Host。公网域名验证要同时检查 Web 服务、frpc 登录与代理成功日志、`/api/health`、首页 HTML 和关键业务 API，避免只看本机 4000 端口。

工程分析/需求分析-2026-05-24-09-58-56.md

@@ -0,0 +1,56 @@
+# 需求分析-2026-05-24-09-58-56
+
+## 开始时间
+
+2026-05-24-09-58-56
+
+## 原始需求摘要
+
+用户要求阅读当前项目并了解整体内容；确认 Gitea 备份仓库 `https://gitea.huijutec.cn/admin/REVOXELSEG_DICOM`；恢复误删的 `Docker部署/` 文件夹；判断 Gitea 中除 `main` 以外的四个 Docker 发布辅助分支是否仍有影响，若不影响当前发布项“ReVoxelSeg DICOM Docker 部署包 v2026.05.21”服务则删除；最后重新部署项目并验证 `https://revoxel.huijutec.cn/` 是否可以正常访问和使用。
+
+## 业务目标
+
+- 恢复主工程中的 Docker 部署资料，保证本机、NAS 与公网隧道部署说明可追溯。
+- 清理不再需要的远端发布辅助分支，避免 Gitea 分支列表混乱，同时保留发布标签、Release 和附件可用性。
+- 重新启动当前服务并验证本机健康接口、页面入口和公网域名。
+- 按工程协作约束记录本次分析、方案、测试与经验，并提交 Gitea 备份。
+
+## 输入与输出
+
+- 输入：
+  - 当前本地仓库 `/home/wkmgc/Desktop/ReVoxelSeg_DICOM`。
+  - Gitea 仓库地址及用户提供的账号信息。
+  - 既有 Docker 发布包与历史工程分析记录。
+- 输出：
+  - 恢复后的 `Docker部署/` 目录。
+  - 本次 `需求分析`、`实现方案`、`测试方案` 文档。
+  - 追加后的 `工程分析/经验记录.md`。
+  - 包含时间戳的 Git/Gitea 备份 commit。
+  - 重新部署后的服务验证结果。
+
+## 影响范围
+
+- 本地文件：`Docker部署/`、`工程分析/需求分析-2026-05-24-09-58-56.md`、`工程分析/实现方案-2026-05-24-09-58-56.md`、`工程分析/测试方案-2026-05-24-09-58-56.md`、`工程分析/经验记录.md`。
+- 远端仓库：可能删除 `docker-standalone-20260521`、`release/docker-machine-20260521`、`release/docker-nas-20260521`、`release/docker-generic-20260521` 四个分支。
+- 运行服务：`WebSite` 构建产物、`tmux` 会话 `revoxelseg-dicom`、本机 `4000` 端口、公网域名 `https://revoxel.huijutec.cn/`。
+
+## 关键约束
+
+- 必须先执行 `工程分析/代码编纂工作流.md`。
+- 最终执行前需再次确认已读 `工程分析/经验记录.md`。
+- 文档备份 commit message 必须包含 `2026-05-24-09-58-56` 与简要描述。
+- 只暂存本次相关文件，避免把既有未确认删除的历史文档或运行态文件混入提交。
+- 部署优先使用 `WebSite && npm run build && npm run serve -- --host 0.0.0.0 --port 4000`，长期运行优先沿用 `tmux` 会话 `revoxelseg-dicom`。
+
+## 风险点
+
+- 当前工作区除 `Docker部署/` 外，还存在多份历史 `工程分析/*-2026-05-*` 文件删除状态，需避免误提交。
+- 删除远端分支属于不可逆清理操作，需先确认发布 Release/Tag/附件不依赖分支指针。
+- 本地 `origin` 指向 `http://192.168.31.5:5002/...`，用户提供的备份仓库为 `https://gitea.huijutec.cn/...`，提交与推送需确认目标一致。
+- 公网访问依赖反向代理、FRP 或现有外部链路，仅本机 `tmux` 服务启动不一定能修复公网链路。
+
+## 待确认问题或默认假设
+
+- 默认假设：用户已授权在确认无影响后删除四个 Docker 发布辅助分支，但不删除 `main`、tag、Release 和 Release 附件。
+- 默认假设：恢复 `Docker部署/` 可优先从当前 Git 历史或远端 `main` 中取回，不需要重写部署方案。
+- 默认假设：本次不恢复或提交既有历史 `工程分析` 文档删除状态，除非后续验证发现这些删除会影响本次工作流核心文档。