发布指纹与哈希冻结，怎样防止“审的是A，发的是B”？

单独保存正文哈希为什么不够

一篇文章的含义不只在正文文件里。图片可能新增正文没有支持的数字，canonical可能指向错误页面，发布日期可能改变动态事实是否仍有效，甚至图注会把“候选验证”写成“生产结果”。因此冻结对象应是一份清单：逐项列出相对路径、角色、字节数和SHA-256，再对规范化清单本身计算总指纹。

规范化清单要排除什么，又必须保留什么

清单应使用稳定的相对路径、固定字段顺序和明确编码，避免绝对目录、生成时间或机器名让同一制品得到不同指纹。与此同时，不能为了“稳定”而排除会影响公开含义的字段。标题、摘要、正文、图片、图注、canonical、版本日期和公开结构化数据发生变化，都应使旧审核失效。

建议做一次边界实验：只改文件时间戳，指纹应保持；只改图中一个字、正文一个标点或canonical一个字符，指纹应变化。若前者变化，说明清单掺入环境噪声；若后者不变，说明冻结范围漏项。

审核、授权与执行怎样消费同一个指纹

独立审阅工件记录审阅人、范围、失败假设和所绑定指纹；负责人授权在发布包外记录目标环境、时窗和同一指纹；执行器领取前重新计算。三者任一不一致就停止。这样可以阻断审核后临时修字、换图或调整日期却继续沿用旧批准。

这里有一个常见反例：团队发现错别字后认为“只是小改”，直接修复并发布。错别字修复本身可能正确，但审核对象已经变化。成本较低的做法是生成新指纹，针对差异做缩小范围的再次审阅，而不是假装旧签字仍覆盖新字节。

这次储备检查暴露的是整站边界

我们在准备七天官网储备时发现：21篇候选放在同一源码树里，即使每个发布包只列三篇，整站构建仍可能把后六天的路由、图片和知识中心条目带出去。逐篇正文哈希正确，无法阻止这种提前公开。

这轮候选实现因此生成独立源码快照，绑定已核验公开基线和精确前序版本。后一天可以预制，但前一天没有验签完成事件，就不能执行；运行版本偏离前序摘要，也应停止，防止把线上修订回退。冻结范围包括app、public、构建脚本、锁文件和公开构建配置，不只是三个page文件。日包绑定源码目录及清单摘要，未知新增文件和未来稿件引用应阻断冻结。这里是候选实现，不代表七天内容已经发布。

公网回读证据链解决“实际发出了什么”；本页补的是构建前发布对象究竟包含哪些输入。两道检查不能互相替代。

发布后还要做不可变公网回读

• 从实际公开地址读取HTML与图片，而不是读取候选目录。
• 核对canonical、标题、日期、正文关键句和图片响应。
• 将原始回读工件保存为不可变证据，并记录核验时间。
• 生产回滚点也要有独立清单和可启动验证，目录存在不等于可回滚。
• 把“字节一致”“内容审核通过”“已公开”“已索引”保持为四种状态。

事实层能确认某个指纹是否被审核、授权和公开回读。推断层可以据此缩小错发原因。仍未知的是搜索系统是否发现、抓取或索引，以及模型是否引用；哈希再精确也不能回答这些效果问题。