用内容哈希做重复文件检测：从思路到实现

磁盘清理里最实在的一块是找重复文件：照片导了两遍、下载目录和文档目录有同一份 PDF、备份目录里躺着历史版本的全家福。按文件名找是不可靠的，按内容找才准——而”按内容”这件事，工程上就是哈希。这篇文章把重复文件检测的完整思路走一遍，从筛选策略到索引设计，再到清理的安全流程。

一、文件名不可靠，内容才算数

重复文件的定义是”内容完全相同的文件”，而不是”名字相同的文件”。现实中的重复文件形态五花八门：

同名同内容：报告.docx 在两个目录各一份
同名不同内容：报告.docx 是不同版本，名字一样内容不同——这不是重复，不能删
不同名同内容：最终版.pdf 和 copy2.pdf 是同一份文件的两次落盘

所以判断重复的唯一可靠依据是内容。比对内容的朴素做法是逐字节比较，但两两比较的开销是 O(n²)，几百个文件就跑不动了。正确做法是给每个文件算一个内容哈希（MD5、SHA-1、SHA-256 都可），哈希相同即视为内容相同——这把比对降到了 O(n) 的哈希计算加 O(n) 的哈希查找。

二、先按大小初筛：砍掉 99% 的工作量

全量哈希的问题是慢。对大目录里的视频、镜像文件，读一遍磁盘算哈希就是几分钟到几小时的 IO。工程上的第一刀是按文件大小分组：

内容相同的文件，大小一定相同。

所以先按 size 建桶，只有同桶的文件才有必要进下一步比较。一个典型的场景是十万个文件里有几百组同大小候选——99% 以上的文件在这一层就被排除了，一次 stat 就够，不用读内容。

大小这一层还能再细化：取文件头尾的少量字节做”局部哈希”（比如首 4KB + 尾 4KB），作为第二层筛选。头部尾部不同，内容必然不同；头尾相同再进全量哈希。对大文件特别有效——几兆的局部读取远比几百兆的全量读取便宜。

候选 = 所有文件
候选 = 按 size 分桶，桶内 >= 2 的进下一轮
候选 = 按 头尾采样哈希 分桶，桶内 >= 2 的进下一轮
结果 = 全量哈希分桶，桶内 >= 2 的是重复组

三层筛选是逐层收窄的漏斗，每一层的成本都比下一层低一个量级。

三、全量哈希的代价与加速思路

全量哈希的瓶颈是磁盘 IO，不是 CPU。机械盘上连续读取的速度上限就是哈希速度的上限，SSD 会好很多。几个加速思路：

并行 IO。 哈希计算和磁盘读取可以流水线化：一个线程读、一个线程算。或者多文件并行哈希，利用 SSD 的并发能力。注意机械盘上并行反而可能因磁头寻道变慢，按硬件类型调整并发度。

分块哈希。 大文件不要一次性读进内存，分块（1~8MB）读、增量喂给哈希库。内存占用可控，也方便做”算到一半发现不同就提前退出”的优化——不过既然已经过了头尾采样这一关，提前退出的收益有限。

抽样哈希的边界。 极端场景下可以只对文件的固定位置采样几段做哈希，速度极快但漏检率上升。这个方案只适合”初步排查”，不适合”确认删除”的决策依据。

缓存哈希结果。 文件的哈希只在内容变化时改变，把 路径 → (大小, 修改时间, 哈希) 缓存下来，下次扫描时大小和修改时间没变就复用缓存。对反复扫描的目录，这个优化能把二次扫描的时间降到几乎为零。

四、哈希碰撞的现实概率

用哈希判等的前提是”碰撞概率可忽略”。这个判断要看具体算法和规模：

MD5 和 SHA-1 已经存在构造碰撞的公开方法，对抗性场景（有人故意制造碰撞文件）下不可用。但重复文件检测是非对抗性的——你磁盘上的文件不是攻击者精心构造的，碰撞来自”自然概率”。

自然碰撞的概率有多小？以 MD5 的 128 位输出为例，生日问题下要产生 50% 的碰撞概率大约需要 2 的 64 次方量级的文件数量——这远远超过任何单机磁盘的文件数。SHA-256 的碰撞概率更是低到可以视为零。所以在个人文件去重的规模下，MD5/SHA-1 的自然碰撞不是需要担心的问题；要担心的是算法实现 bug、读取不完整（文件读到一半被修改）这类工程错误。

实操建议：优先用 SHA-256（今天没有理由用更弱的），对结果保持”哈希相同 + 大小相同”的双重校验，并且在清理前抽查几组——把工程严谨性花在流程上，比花在算法选择上更值。

五、结果的索引化：像数据库一样建映射

扫描结果值得结构化存储，而不是扫完即弃。一个简单的关系模型：

files(path PK, size, mtime, hash)
dups(hash, count, total_size)   -- 视图或物化表

核心映射是 size → [files] 和 hash → [files] 两个多值索引。用 SQLite 落地是顺手的选择——查询重复组、按目录统计、按类型过滤，SQL 一句的事：

SELECT hash, COUNT(*) AS n, SUM(size) AS waste
FROM files
GROUP BY hash
HAVING n > 1
ORDER BY waste DESC;

这个”浪费空间”的排序特别有用：优先处理占用空间最大的重复组，清理收益最高。比按文件数量排序的性价比高得多。

索引化还有一个价值是增量维护。文件系统变动是常态，把索引持久化之后，后续扫描只需要处理变更部分（结合 mtime 快速判断），重复检测从”一次性工具”变成”可反复运行的巡检”。这是数据库思维对文件工具的直接借鉴：先建索引，再谈查询效率。

六、批量清理的安全流程

找到重复组只是中间结果，删除才是高危动作。安全流程的关键词是保留一份、预览、可回滚：

保留策略要明确。 每组重复文件只删副本、留一份原件。”留哪份”要有确定性规则（比如留路径最短的、留修改时间最早的、留指定目录下的），规则模糊就会误删。

先预览后删除。 清理前列出完整的删除清单：哪个路径的哪个文件会被删、释放多少空间、保留哪一份。逐组过目或者至少抽查。我自己在 7AA7工具箱里做重复文件清理时，它就是这个流程——内容哈希分组出结果后先出预览列表，确认了才动，这一步能挡掉绝大多数误伤。

走回收站，不直接物理删除。 回收站是误删的唯一缓冲。批量删除宁可慢一点，也别用”永久删除”的快感换风险。回收站满了之后手动清，比删错了找不回来强。

删除后核对。 抽查保留的那份文件能正常打开、路径无误。批量操作的验收不能省。

备份先行。 真要大规模清理（比如一次清几十 G），先把删除清单导出存档，重要数据先做备份再动手。文件删除是不可逆的，流程的严谨程度应该和数据的价值匹配。

重复文件检测是少数”技术简单、流程重要”的场景：哈希的数学没什么悬念，工程上的分层筛选和索引化决定体验，而清理的安全流程决定这个工具敢不敢用。三层都做扎实，磁盘清理才是一个真正可靠的能力。