如何在不重新哈希的情况下可靠检测文件变更以安全缓存SHA-256哈希

跨平台通用快速检测策略 #

这些方法能在绝大多数场景下快速验证文件是否变更，仅当检测到变化时才重新计算SHA-256：

1. 多属性组合校验（优先推荐） #

同时检查以下属性，大幅降低误判概率：

• 文件大小：内容变更大概率会改变大小，这是最快的检测项
• inode编号（Linux/macOS）/文件索引编号（Windows）：文件被替换（如删除原文件后新建同名文件）时，该编号会变化
• 修改时间（mtime）：虽可能被伪造，但结合前两项后，篡改难度显著提升
• 创建/变更时间（ctime/birthtime）：Linux下ctime会在文件内容、权限等任何属性变更时更新；macOS/Windows的birthtime为文件原始创建时间，常规手段无法修改

注意：这种组合仍存在极端伪造的可能，但已能覆盖99%以上常规场景。仅当所有属性都匹配缓存值时，才复用SHA-256哈希；只要有一项不匹配，就重新计算哈希。

2. 分段哈希校验 #

仅计算文件开头、结尾和中间几个固定位置的小块哈希（比如各取1KB），与缓存的分段哈希对比：

• 优点：计算量远小于全量哈希，大文件场景速度提升明显
• 缺点：存在极小概率碰撞（不同内容的分段哈希相同），可通过增加分段数量降低风险
• 实现思路：缓存时同时存储全量SHA-256和分段哈希，检测时先对比分段哈希，一致则复用全量哈希，不一致则重新计算全量哈希

平台特定优化技术 #

Linux #

• 依赖stat的change time (ctime)：Linux下ctime会在文件内容、权限、所有者等任何属性变更时更新，常规手段无法伪造（修改系统时间属于极端场景，会影响大量系统行为）
• 扩展文件属性（xattrs）：给文件添加自定义属性（如存储缓存的哈希标识），读取速度快，且除非手动修改，否则不会随文件内容变更而变化

macOS #

• 文件系统元数据birthtime：HFS+和APFS文件系统会记录文件原始创建时间，无法被常规工具修改，结合mtime和大小可提升检测可靠性
• fstat的st_flags：检查文件特殊标记，部分场景下可识别文件是否被修改

Windows #

• 文件索引编号（File Index Number）：NTFS文件系统中每个文件有唯一索引编号，文件被替换时编号会变化，读取速度极快
• GetFileInformationByHandle获取的FileChangeTime：该时间戳会在文件内容或属性变更时更新，比mtime更可靠
• 备用数据流（ADS）：将缓存哈希存储在文件的备用数据流中，读取时直接对比，无需额外缓存文件

总结 #

若追求绝对可靠，只有全量SHA-256哈希能满足需求，但上述方法可在99%以上场景中快速验证文件是否变更，避免不必要的全量哈希计算：

1. 优先使用多属性组合校验，实现简单、跨平台且性能最优
2. 大文件场景搭配分段哈希进一步提升速度
3. 平台特定技术可作为补充，进一步降低误判概率

内容的提问来源于stack exchange，提问作者Omer Greental