遗留系统生产化：签名身份、LKG 回退与清站重装

一键部署最难的不是“一键”

遗留系统常由编译前端、PHP/MySQL、Node.js WebSocket 和 Android 构建链共同组成。把启动命令写进 install.sh 并不难，真正困难的是重复执行不能破坏数据、更新失败可以回退、签名身份不能改变、清站重装仍能恢复关键资产。

生产交付应当被视为一条状态迁移链，而不是一组命令集合。每一步都要有前置条件、验证结果和失败处理。

先把环境差异参数化

域名、站点目录、数据库、PHP-FPM Socket、Node.js 路径和内部端口不应散落在源码与脚本中。安装器读取统一配置，并在执行前检查必要二进制、目录权限、证书、数据库连接和端口占用。

首次安装、重复更新和清站重装是三种不同路径，但应共享同一套检测与验证逻辑。

签名身份必须独立于站点目录

Android 签名证书、密码配置和验证材料一旦随站点目录一起清理，新包将失去与历史版本一致的身份。解决办法是把签名资产放入站点目录外的受控保险库，部署过程只按最小权限读取。

清站脚本也必须从站点目录外执行，先验证保险库、备份和目标路径，再清理明确范围，避免脚本把自身或恢复材料一起删除。

active 与 LKG 让模板更新可回退

活动模板不应该被新上传文件直接覆盖。新版本先进入候选区，完成结构、依赖、真实构建、对齐、签名和验签后，再原子提升为 active；上一份已经验证可用的模板保留为 LKG（Last Known Good）。

active 和 LKG 都保存 SHA-256。任一校验异常都停止发布，而不是继续覆盖。这样构建链故障或资源损坏时，可以快速回到上一份已知可用状态。

数据库更新必须幂等

• 迁移有唯一版本记录，重复执行不会重复添加字段或数据。

• 变更前自动备份配置与数据库，变更后执行结构和关键数据检查。

• 运行数据、上传文件和数据库卷不随应用容器更新被重建。

• 失败时明确停在哪一步，并保留可人工恢复的现场。

验收要覆盖完整生产链

一次有效的生产验收应同时检查 HTTPS、Nginx、PHP-FPM、PM2/WebSocket、内部端口、数据库状态、前端资源、模板哈希和签名验签。只看到首页返回 200，并不能证明后台、实时链路和构建系统可用。

最终目标，是让一个复杂遗留系统在数据不能丢、签名身份不能变、旧版本需要回退的约束下，仍然可以重复部署和独立验证。