从打包上传到 push 即上线：把 CD 接通

上线之后每次发版都要在本地 git archive 打包、scp 上服务器、解压、改端口、重新构建。1.9G 的机器构建前端要动 swap，一次十几分钟。

接通 CD 之后这些都没了：推 main，CI 全绿后自动构建镜像推到 GHCR，SSH 到服务器 pull + up，健康检查不过就回滚到上一个版本。

配置里有两处是配好之后才发现会坏事的。

第一处是健康检查的探测地址。部署脚本原本 curl http://127.0.0.1/，看起来天经地义。但这台机器上 80 端口是宿主机的 nginx，站点块的 server_name 是域名，Host 是 IP 的请求命不中它，返回 404。于是健康检查永远不通过，每一次正常发布都会被判定失败并自动回滚——回滚还是"正确地"执行了我没打算让它执行的动作。

改成从 .env 里的端口配置推导，直接打 gateway 容器：

GATEWAY_PUBLISH=127.0.0.1:8081:80   # → 探测 http://127.0.0.1:8081

第二处是镜像仓库的权限。仓库是私有的，GHCR 上的包默认跟着私有，服务器 pull 会被直接拒绝。要在服务器上先 docker login ghcr.io，用一个只有读包权限的令牌。

端口配置也一并收进了 .env。以前 gateway 端口是就地改 compose 文件，重新上传代码就被仓库里的 80:80 覆盖回去，每次都要重跑那条 sed。现在是 ports: ["${GATEWAY_PUBLISH:-80:80}"]，值在 .env 里，代码更新不会碰它。

第一次跑之前我卡了两件事没做，都会导致发布失败：端口没配进 .env（那样 up 会去抢 80，把站点弄停），以及没登录 GHCR（拉不到镜像）。顺序是先配这两件，再推代码。

推上去之后 CI 跑一轮，CD 接着跑；构建在 runner 上完成，服务器只负责拉和起。那台 1.9G 的机器从此不再参与打包，构建内存墙这件事跟着消失了。