压缩包的 SHA 不同，文件却可以相同：发布验收要比较哪一层

摘要：重新打包后，ZIP 大小与 SHA256 都变了，是否就代表程序被修改？本文结合一个离线工具的真实发布材料，区分压缩包字节、文件清单、解包内容与运行验收，说明怎样给“内容一致”划定准确范围。

把同一组文件再次压缩，可能得到另一个包指纹。遇到这种差异，直接判定源码变化会误报；看到文件数量相等就放行，又可能漏掉错包。关键是先说明究竟在比较什么。

包指纹回答的是整个 ZIP 是否一致

10 月 28 日保存的 evidence-ledger 发布材料中，有三份包：

三者都包含 10 个文件，整个 ZIP 的 SHA256 各不相同。没有显式目录项，也不代表文件都在同一层：带斜杠的条目名已经表达了子目录结构。

包哈希覆盖压缩数据和 ZIP 结构。条目路径、顺序、时间、附加字段或压缩表示发生变化，都可能改变它。这里只能确认包字节不同，不能单凭哈希推断某个源文件被修改，也不能把差异全部归因于“压缩率不同”。

本地平铺包与公开包的文件内容可以相同，条目顺序和显式目录项却不同。检查保留的条目信息还能看到，公开包的 SKILL.md 有附加字段，本地两包没有。本文没有进一步分解每一种差异对包大小的贡献。

文件级验收先比集合，再比内容

公开包的历史比较记录逐项列出了相对路径、字节数和 SHA256，10 个文件均与发布目录匹配。这个结果需要同时成立两件事：预期文件都存在，也没有混入额外文件。

只循环检查“预期的 10 个文件是否正确”，可能漏掉第 11 个调试文件；只比较数量，又可能把缺失的文件和多出的文件相互抵消。可把验收流程写成：

检查条目路径和重复项
核对约定的根目录布局
实际文件路径集合 == 预期文件路径集合
逐文件比较解压后字节数与 SHA256
另行记录目录项和需要保留的元数据

这里比较的是 ZIP 条目解压后的原始字节，不做换行替换、编码转换或 JSON 格式化。否则，“规范化后相同”会被误写成“逐字节相同”。

路径也不能只取最后一段。examples/config.json 与 tests/config.json 是不同对象。若 ZIP 含重复路径，应先报错，不能直接塞进字典，让后一项悄悄覆盖前一项。对越界路径等异常，也应在写入磁盘前处理。

文件相同不代表交付结构可互换

比较嵌套包时，可以按已知约定移除一层 evidence-ledger/ 前缀，再核对内部内容。但这个映射只是为了回答内容是否一致，不能把原包的根目录要求一起抹掉。

例如，使用方若要求 ZIP 根目录直接存在 SKILL.md，嵌套包即使每份文件都正确，也不满足该入口条件。验收结论应分别记录“映射后文件内容一致”和“原始布局是否满足目标要求”。

同样，文件哈希不涵盖解包后的权限、符号链接语义或解释器环境。运行方式依赖这些条件时，还要按交付契约另查；不能由 10 个文件内容一致，推导出所有环境的运行行为一致。

保存两层清单，才能解释差异

可为实际下载的包保存来源、时间、大小和完整 SHA256，另附文件清单。包指纹便于核对收到的是否为预期传输对象；文件清单便于定位差异究竟涉及哪些内容。哈希只有与可信的参考记录一起使用，才能支撑相应比较；它本身不证明发布者身份、代码正确或平台审核通过。

若目标是每次构建产生完全相同的 ZIP，还需约束排序、时间、权限、附加字段、压缩工具和参数。那是可复现打包的目标，不能把一次文件级比较成功当成已经达成。

本文依据 10 月 28 日留存的三个 ZIP、发布清单与公开包逐文件比较记录，10 月 30 日仅只读复核材料，没有重新打包、发布或运行功能测试。历史结果支持“公开包中的 10 个文件与相应 release 内容一致”；不支持“三个 ZIP 完全相同”，也不替代后续的运行与发布状态核验。