重复文件查找指南:按内容哈希找出一模一样的文件

我自己的照片库到去年大概有六万张,里面塞着相机直出、微信压缩版、修图导出的好几份。表面看名字都不一样:IMG_0231.jpg、IMG_0231(1).jpg、IMG_0231_副本.jpg。靠肉眼根本分不清哪些是真重复,哪些只是名字像。后来我改用按内容比对的办法,一个下午腾出了十几个 G。这篇就把这套办法讲清楚。

为什么要按内容哈希,而不是按文件名

文件名是给人看的,不是给机器判重用的。同一份文件可以叫一百个名字,两份完全不同的文件也可能恰好同名。光看名字判重,要么漏掉真重复,要么误删了不该删的。

内容哈希走的是另一条路。它把文件的每一个字节喂进一个加密哈希函数(比如 SHA-256),算出一段固定长度的摘要。两个文件只要有一个字节不一样,摘要就会完全不同;反过来,摘要相同就意味着字节完全一致。于是判重这件事变得干净利落:哈希相同就是重复,哈希不同就不是,跟它们叫什么名字、放在哪个文件夹、什么时候改过,都没有关系。

什么算"完全重复",什么不算

这里要先把界限说清楚,免得期待错位。

按哈希判出来的是字节级完全重复,也就是两份文件逐字节一模一样。它不会把"看起来差不多"的文件认作一对。举几个常见的反例:

• 同一张照片,原图和压缩版,像素肉眼几乎看不出差别,但字节不同,哈希不同,不算重复。
• 同一份合同,一份是 Word,一份导出成 PDF,内容一字不差,但文件格式不同,哈希不同。
• 同一段文字,一份末尾多了个空行或者改了换行符,哈希也会变。

这不是缺点,而是设计取舍。完全重复的判定是确定的、可复现的,也最安全:工具说这两份一样,它们就真的一样,你删掉其中一份不会丢任何信息。相似度判断则要靠模型猜,容易误判,清理硬盘这种"删了就没了"的场景,我宁可要确定性。

一个真实的分组例子

假设你从文件选择器里选了五个文件,工具读取每一个,算出 SHA 摘要,然后按摘要分组:

• 合同_v2.pdf,哈希 a1b2c3...
• 合同最终版.pdf,哈希 a1b2c3...
• 合同_v2(1).pdf,哈希 a1b2c3...
• 发票.pdf,哈希 d4e5f6...
• 发票_扫描件.pdf,哈希 9a8b7c...

结果一目了然:前三个文件名各不相同,哈希却完全一致,它们是同一份合同的三个副本,留一份就够。后两张发票虽然名字像,哈希不同,是两份不同的文件,都得留。如果只看文件名,你很可能会把"发票.pdf"和"发票_扫描件.pdf"当成一对去合并,那就错了。哈希帮你避开了这个坑。

清理硬盘和照片库的实战顺序

我的习惯是分两步走,不一次删太狠。

第一步,先找出重复组。把待清理的文件夹里的文件选进 重复文件查找器,让它按哈希分组,导出那份 Markdown 清理报告。报告里清清楚楚列出哪几个文件是同一份、各自多大、加起来占了多少空间。

第二步,带着报告去删。工具本身只负责找,不动你的文件,删除这一步永远由你在浏览器外、对着报告手动确认。每个重复组留最早的一份或者放在最顺手目录的那份,其余删掉。照片库我一般保留相机直出的原图,删掉那些压缩转发版。

如果你只是想确认两个具体文件到底是不是一模一样,而不是批量找,那用 文件校验和对比 更直接,它专门做两份文件的逐位比对。

文件不上传,哈希在本地算

清理文件常常牵涉合同、发票、私人照片这类不想外传的东西,所以"会不会上传"是个绕不开的问题。

这个工具的哈希计算和分组全部在浏览器本地完成,文件不会离开你的设备,不发往任何服务器。你可以断网试一下,功能照常。原理上也不需要联网:读取文件、算 SHA 摘要、比对分组,这些都是浏览器自己就能做的运算。对个人用户来说,省去了上传等待;对处理敏感资料的人来说,这是底线要求。

我自己的一点体会

真正让我养成定期去重习惯的,不是省下的那点空间,而是找东西变快了。以前一个项目文件夹里堆着五六个"最终版",每次都要逐个点开确认哪个是真的最终版。现在每隔一阵跑一遍重复查找,把字节相同的副本清掉,文件夹一下子清爽,需要的那一份一眼就找到。判重交给哈希,删不删我自己拿主意,这个分工让我用得很踏实。

---

Made by Toolora · Updated 2026-06-13