2026-05-21-14-19-12 记录Docker三版本Release发布

工程分析/经验记录.md

@@ -1531,3 +1531,21 @@ C. 解决问题方案
 D. 后续如何避免问题
 
 后续若维护 Docker 独立包，应优先在 `ReVoxelSeg_DICOM_Docker` 目录内修改和验证，不要依赖主工程相对路径。根目录 Compose 文件中，本机版保留为 `docker_compose.yaml`，NAS 版使用 `docker_compose.nas.yaml`，避免同名文件冲突。独立分支内容结构与 main 不同，推送前必须检查目录纯净度，确认不含工程分析、软著材料、node_modules、dist、data、exports 等无关内容。
+
+## 2026-05-21-14-19-12 Release 多版本发布要用 tag 固化配置差异
+
+A. 具体问题
+
+用户要求在 Gitea Releases 中发布机器直接部署版、NAS 直接部署版和通用版三个版本。其中通用版必须删除具体 FRPC 反向代理信息，避免固定服务地址、token、远端端口和公网域名限制其他环境使用。
+
+B. 产生问题原因
+
+独立 Docker 包的 `docker_compose.yaml` 默认面向当前机器部署，`docker_compose.nas.yaml` 面向 QNAP 绝对路径部署；如果只发布同一个分支源码包，用户下载后仍需判断使用哪个 Compose，通用版也会夹带当前环境的 FRPC 敏感配置。Gitea Release 又是以 tag 为版本锚点，必须为不同部署语义固定不同 tag。
+
+C. 解决问题方案
+
+在独立 Docker 仓库中从 `docker-standalone-20260521` 派生三个发布分支：机器版保留当前本机根目录 `docker_compose.yaml`；NAS 版将 NAS Compose 复制为根目录 `docker_compose.yaml`；通用版重写根目录 `docker_compose.yaml`，使用 `.env.example` 和环境变量占位 FRPC 信息，并删除固定 NAS Compose。随后为三种配置分别创建 tag，通过 Gitea API 创建三个 Release。发布前对三种 Compose 执行 `docker compose config`，并用 `rg` 检查通用版不含固定 FRPC 信息。
+
+D. 后续如何避免问题
+
+以后发布多部署形态时，不要只改 Release 文案；应使用不同 tag 固化不同文件状态。包含具体环境配置的版本可以保留当前内网、域名和 FRPC 信息；通用版本必须使用环境变量或占位模板，并在发布前全目录搜索确认没有遗留服务地址、token、远端端口和固定域名。创建 Gitea Release 后，应再通过 API 或页面确认 Release、tag 和目标提交一致。