247 Admin：部署档口入库码后台回写版本到生产服务器

类型：部署
父级大工单：#14
所属 MVP / 版本：#15 / Admin 生产部署
状态：已完成，待用户验收
日期：2026-08-15
Gitea 工单：#247

背景与目标

生产 Admin 原来运行 17c2d45，尚未包含 #245 按货运单号直查顺运宝和 #246 档口入库码后台批量回写。本任务把固定提交 7736ab7 构建并发布到 185.216.248.75，继续通过 https://buy.833729.com 提供服务。

发布前预检发现生产数据库已于 2026-08-15T08:53:04Z 记录 schema v25，两个新增字段、批次索引和包含 queued 的状态约束均已存在；但线上仍是只支持 v24 的旧进程。旧进程尚未重启所以仍在线，一旦重启将拒绝连接版本更高的数据库。本次发布因此同时恢复“线上二进制与数据库版本一致”的安全状态。

最终方案

在 Windows 系统临时目录建立 7736ab7 detached worktree，与主工作区未提交的 Client 文件隔离；使用固定 Go 1.23.0 完成 vet、全量构建和全量测试，再交叉编译 Linux amd64 静态二进制。
上传后核对本地、暂存和最终 release 的 SHA-256、文件大小和 ELF 类型；正式 release 继续通过符号链接复用 /opt/cmautobuy/config.yaml 和 /opt/cmautobuy/data，没有复制或输出凭据。
因生产 schema 已是 v25，先在不对公网开放的 127.0.0.1:18081 使用生产环境启动目标二进制，确认数据库自检、稳定配置和登录页均正常，随后才进入切换窗口。
三次核对运行中的 SYB 同步、AI 匹配、档口入库码排队/回写均为 0。切换前使用生产业务账号生成 --no-tablespaces 单事务逻辑备份，权限设为 0600，完成 gzip、建表段和 SHA-256 校验。
停止 systemd 后原子切换稳定二进制链接并启动。目标版本通过本机登录页检查后，再核对 schema v25 字段/索引/约束、systemd、监听、Nginx、公网 HTTPS 和最新静态资源标识。
预检发现改变了原回退条件：旧 17c2d45 不能在 v25 上直接启动。当前只允许修复前进；只有确认没有任何新业务写入时，才能同时恢复数据库备份和原 release。不得只切旧二进制。
部署过程没有触发顺运宝同步、档口入库码匹配/回写、AI 匹配、采集、采购、下单或付款。

改了哪些

/opt/cmautobuy/releases/7736ab7/：新增并启用目标 Admin release。
/opt/cmautobuy/cmautobuy-admin：稳定链接从 17c2d45 原子切换到 7736ab7。
/opt/cmautobuy/backups/autobuy-before-247-20260815T093211Z-v25-notablespaces.sql.gz：新增部署前生产 v25 备份。
docs/task/247-admin部署档口入库码后台回写版本.md：新增本次部署归档。

原 17c2d45 release 继续保留，但不能单独作为 v25 应用回退。服务器上传暂存文件和预检日志已删除；本地 detached worktree 已移除。已校验的 Linux 二进制暂时保留在系统临时目录 cmautobuy-deploy-247-20260815-172931/artifacts，不在仓库中且不含配置或数据。

验收结果

验收标准	结果
发布物只来自固定提交 `7736ab7`，固定 Go 1.23.0 验证通过	通过
切换前 SYB、AI 和档口入库码运行数均为 0	通过（三次核对）
数据库备份权限、gzip、建表段和哈希校验通过	通过：`0600`、31 个建表段
本地、上传和最终 release 哈希一致	通过
systemd active/enabled，只监听 `127.0.0.1:18080`	通过
schema v25 字段、索引和状态约束自检通过	通过
本机和公网根路径、登录页、静态资源正常	通过
配置、AI 密钥和业务记录保持，未触发真实业务动作	通过

发布结果：

目标二进制：28,012,696 字节，SHA-256 a6bc35265c57942a5ffc54e7a547ca129b14f439ce1bf494c4d06eb10162cef1。
数据库备份：4,845,905 字节，SHA-256 1f0b763a4c50cffd0bfec64ea76026c6da9922f23751632a2e8870ab7532a891。
新服务 PID 为 30494，启动时间 2026-08-15 17:32:41 CST；启动日志显示数据库就绪， fatal、panic 和迁移错误均为 0。
MySQL 服务端为 8.4.8，schema 为 v25；apply_batch_id、apply_queued_at、 idx_inner_code_apply_batch 和含 queued 的状态约束均存在。
本机根路径 303、登录页 200；公网根路径 303、登录页 200、app.js 200，且最新脚本包含 apply_batch_id 标识。
部署后运行中的 SYB、AI 和档口入库码后台任务均为 0；档口入库码记录仍为 110 条。
稳定配置和数据链接正常，AI 密钥文件可由服务读取且权限仍为 0600；未读取或输出内容。

测试

执行的命令：
- 隔离 worktree：GOTOOLCHAIN=go1.23.0 go vet ./...、go build ./...、 go test ./... -count=1
- GOOS=linux GOARCH=amd64 CGO_ENABLED=0 go build -trimpath -ldflags='-s -w'
- 上传前后 sha256sum、stat、file
- 独立端口生产环境启动预检、生产运行态 SQL、mysqldump --no-tablespaces、gzip -t
- readlink、systemctl、ss、nginx -t、journalctl、本机和公网 curl
结果：固定 Go 1.23.0 验证、静态构建、启动预检、备份、切换及全部发布后健康检查通过。
没验证到的部分：未使用生产账号登录后人工选择超过 20 条档口入库码并观察后台进度；未向真实顺运宝发送匹配、删除或写入请求；未触发真实同步、AI 匹配、采集、采购、下单或付款；未实际执行数据库覆盖恢复或旧 release 回退。当前环境仍没有独立 MySQL 8.4 _test 库执行 v24→v25 DDL 演练，但生产现有 v25 已由目标二进制启动自检通过。

遗留问题

旧 17c2d45 只支持 schema v24，不能单独启动。生产发生故障时优先修复前进；如确需恢复本次备份，必须先确认备份后没有需要保留的新业务数据，并同时恢复数据库与原 release。

6.1 KiB Raw Blame History Unescape Escape