旧机复测：同版本安装包，三家解压工具CRC校验结果居然对不上

前两天翻出一台吃灰的旧笔记本，i5-4200M，4G内存，机械硬盘。想着正好拿它当测试机，验证一下压缩包完整性校验这事儿——毕竟之前老有人跟我说「XX解压工具自带修复，牛逼得很」，我寻思着，修复个啥？

测试条件先说清楚，别回头说我瞎黑：

• 同一个安装包，来源可追溯，下载后立即算哈希存档，确认源文件没问题
• 三家工具：WinRAR 6.24、7-Zip 23.01、Bandizip 7.32
• 操作：对同一个 2.3G 的包执行「测试」（Test）操作，记录 CRC 校验结果和耗时
• 旧机跑三遍，每遍之间重启清缓存

结果：

第一遍，7-Zip 报 CRC 错误，另外两家说 OK。我第一反应是 7-Zip 的锅，但不对劲——换了个包，7-Zip 又说 OK。

第二遍，我拿 certutil -hashfile 手动算了一遍 SHA256，跟原始哈希一比对，7-Zip 报错的那个包，其实是真的坏了。另外两家所谓的「OK」，只是没做完整校验就放行了。

第三遍最离谱。Bandizip 在「测试」界面显示通过，但我解压到目录后，用 fc /b 对比原文件，逐字节比下来，有个 40 多字节的差异。也就是说，它测试说没问题，实际解出来就是坏数据。

我的判断依据：

1. 别信「测试通过」这个绿灯，那是工具自己说的，不是文件自己说的。要验证，就自己算哈希，certutil 系统自带，一行命令的事。
2. 7-Zip 报 CRC 错的时候，我一开始也烦它，但后来想明白了，它报错是它肯告诉你，另外两家不报不代表没问题。
3. 那台旧机上，7-Zip 测试 2.3G 包花了 4 分 12 秒，Bandizip 只花了 1 分 50 秒。我当时还夸 Bandizip 快，现在回头看，快是有原因的——它压根没完整读一遍。

踩坑细节： 这个包后来我用 7-Zip 的「修复压缩包」功能试了一下，修出来的文件大小对，但里面两个 dll 的 CRC 还是错的。也就是说，修复功能在数据级损坏面前基本是安慰剂。最后我是从源站重新下了一遍，才算完事。

所以我一直说，所谓「必备解压神器」的招牌功能，大部分是你用不上、或者用了也白用的东西。真正能兜底的，是你自己动手算一遍哈希。系统自带命令就能干的事，非得装个带各种弹窗的玩意儿？

最后问一句： 你们手头那些所谓「测试通过」的压缩包，真拿 certutil 对过原始哈希吗？还是说，从来没人告诉过你可以这么干？