同一批文件挪个目录，WinRAR压缩率差出3%，我拿哈希对比才搞明白

先说结论：文件系统簇大小和压缩软件的字典匹配会互相影响，同一个压缩包换块大小重压，体积可能差出个位数百分比。

起因

上周整理项目归档，把 3000 多个小文件（平均 50KB 左右，主要是日志和配置）从一个 4K 簇的机械盘分区挪到另一块 64K 簇的固态分区，再用 WinRAR 5.0 压成 RAR5，字典设 128MB，固实压缩开。结果压出来比原来大了 3.2%。

按理说文件内容没变，压缩算法也没变，体积不该动。我一开始怀疑是固实压缩的排序问题，但两次压缩的参数截图对过，一模一样。

排查过程

1. 先算源文件哈希：certutil -hashfile 批量跑，两次源文件 SHA256 完全一致，排除文件被改。
2. 再算压缩包哈希：体积变了，哈希当然不同，正常。
3. 用 fsutil fsinfo ntfsinfo D: 看簇大小，老分区 4096 字节，新分区 65536 字节。
4. 关键一步：把小文件逐个读出来，对比「文件实际大小」和「占用空间」。在 64K 簇上，一个 50KB 的文件实际占 64KB，多出来的 14KB 是簇尾填充。WinRAR 读的是逻辑文件内容，按理不该受簇大小影响……但固实压缩会按文件顺序做块匹配，小文件一多，块边界和字典窗口的错位就放大了。

验证

我不信邪，做了两组对照：

• A 组：同一批文件，分别在 4K 和 64K 簇分区各放一份，用完全相同的 WinRAR 参数压。结果 64K 簇那份大了 3.1%。
• B 组：把文件数从 3000 砍到 300（只留大文件），再对比两分区。这次体积差只有 0.2%，基本在压缩噪声内。

结论很明确：小文件数量越多，簇大小对压缩率的影响越明显，因为固实压缩的块匹配会被文件边界切碎，簇尾填充虽然不进压缩流，但文件在目录里的排列顺序和读取顺序受影响，间接改变了字典命中率。

我的看法

我不否认自动优化工具省事，但这类问题靠「一键优化」是查不出来的，必须手动控制变量。我的习惯是：

• 压缩前先看源文件簇大小，小文件多就统一挪到 4K 簇分区再压；
• 固实压缩对小文件敏感，超过 1000 个小文件时我会考虑拆包；
• 每次压完用 rar lt 看块统计，对比字典命中率，不靠肉眼看体积。

另外说一句，软领那套自动优化确实没广告，适合不想折腾的人，但真遇到这种体积差 3% 的细节，还是得自己拿数据对账。

抛个问题

你们压大量小文件时，会不会先统一簇大小再压？还是直接用固实压缩一把梭？有没有人试过 NTFS 压缩属性和 RAR 固实压缩叠着用，体积能再小多少？