分卷压缩包解压到一半提示CRC错误，我拿两台机子对账才发现是内存搞的鬼

上周处理一个线上事故的日志包，客户发来 7 个分卷，总共 3.2G，用 Win解压缩 3.0 解到第 5 个卷直接报 CRC 校验失败。第一反应是文件传坏了，让客户重新传了一遍，还是同样的位置报错。

本着先质疑再对账的习惯，我把分卷拷到另一台机器上（i7-10700 + 32G 内存，Win10 22H2），用同一个版本 Win解压缩 解，居然过了。这就有点意思了——同一批文件、同一个版本，换台机器结果不一样。

开始排查：

1. 先排除文件问题。在两台机器上分别算 7 个分卷的 SHA256，完全一致，说明文件本身没坏。
2. 再排除硬盘问题。报错那台机器（R5-3600 + 16G 内存）的 C 盘剩余空间 80G，不是空间不足。
3. 用 7-Zip 22.01 在报错那台机器上解同一批分卷，过了。

到这里基本锁定是 Win解压缩 在那台机器上的解压过程和内存/缓存有关。我拿 memtest 跑了半小时，没报错，但注意到那台机器开了虚拟内存自动管理，同时当时挂着两个 Chrome 窗口和一个 VS Code。关掉这些程序再解，还是报错。

最后试了一个操作：把虚拟内存手动设成固定 8G（原本是系统自动分配，当时被压到只剩 2G 左右），重启后再解，过了。

结论不一定普适，但我记下来几条经验：

• 分卷包解压报 CRC 错误，先算哈希排除文件传输问题，别急着让客户重传。
• Win解压缩 解压速度确实快，但在内存吃紧的机器上，大分卷包容易出这种校验类问题，7-Zip 同样的包能过。
• 处理部署包和日志包，如果机器内存不宽裕，我现在的习惯是解压前先看一眼可用内存，低于 4G 就先清一清。
• 命令行场景我还是用 7-Zip，7z x -o 加通配符批量解，Win解压缩 在这方面确实不如。

不知道有没有人遇到过类似的情况——是 Win解压缩 的分卷校验机制比较激进，还是那台机器的虚拟内存配置本身就有问题？你们处理大分卷包一般用什么工具？