生产发布怎样证明“能回滚”，而不是只留一个旧目录？

候选验证不能只比较入口文件

静态站点或服务端构建通常包含脚本、样式、图片、路由数据和运行入口。只比较一个主文件的哈希，可能漏掉旧图片残留、缺失分块或多余调试文件。当前候选对候选目录及新回滚副本生成完整清单，记录每个相对路径、文件大小和SHA-256；切换后的当前目录目前只核对BUILD_ID，全目录再次比对仍是待补硬门。

清单还应拒绝符号链接和特殊文件。原因很实际：同样的相对路径可能指向候选目录之外，既破坏可复现性，也让回滚边界失去意义。目录验证通过只说明制品一致，不代表生产进程已经加载这份制品。

构建标识解决“文件是新的，进程还是旧的”

部署脚本完成目录切换后，进程管理器可能重启失败，也可能启动了错误路径。为此，候选构建生成独立构建标识；切换后核对当前磁盘标识，再检查进程的实际脚本路径、在线状态和本次启动时间。条件全部满足，才能继续健康检查。

如果健康接口只返回200，却没有暴露运行构建标识，证据仍有边界。可以通过固定进程路径、磁盘标识和新鲜启动时间降低串版风险，但更强的做法是让健康接口直接回传构建标识。当前缺少这一项时，应如实写成待补强，而不是宣称绝无串版可能。

回滚点必须先验证，再替换旧回滚点

如果每次发布都直接覆盖唯一回滚目录，一旦新备份不完整，最后一个可用恢复点就被破坏。当前候选先把现行版本形成新的回滚候选并核对完整清单，通过后才替换上一回滚点。项目目录只保留当前版本与一个清单已验证回滚点，更早版本依靠版本库或制品哈希恢复。

实际失败路径先隔离本次失败目录，再恢复回滚目录，随后重启并执行运行回读。首个样本的前三次失败都触发这条路径：原版和v3因回滚表面验收不完整进入不一致阻塞，v4才以无回滚失败完成可验证回滚。数据库写入后的精确补偿不能用宽泛删除代替；本次没有数据库补偿真实故障注入证据，状态仍为未知。

一次可复核的故障演练应当检查什么

• 候选缺少一个资源文件时，是否在生产切换前停止。
• 进程重启失败时，是否恢复旧目录并再次确认健康。
• 运行脚本路径错误时，是否拒绝把在线状态当成成功。
• 数据库登记失败时，页面与数据是否回到一致状态。
• 回滚动作自身失败时，是否保留全部错误而不是只报告第一个。

2026年9月1日的首个生产样本最终完成PM2状态、健康接口、不可变公网回读、数据库三项内容资产和管理API闭环。它只证明第三次失败的可验证回滚和第四次发布成功，不能把前两次不完整回滚写成成功，也不足以证明长期稳定；数据库补偿故障路径仍未验证。