硬盘报警那天我打开文件管理器，才发现同一个目录里躺着三套几乎一样的照片：2023 年换手机导过一遍，换备份软件又导过一遍，中间还手动拷了一份。名字全不一样，按文件名去重根本没用。这周把 Czkawka 12.0.2 拉下来认真跑了一遍，数据和坑都记在下面。
它不只会找重复文件
Czkawka 是 Rust 写的开源磁盘清理工具，GitHub 上 34.6k star，12.0.2 版在 2026 年 9 月 9 日发布，仓库到写这篇的时候当天还有新提交。功能一共十来个：重复文件、相似图片、相似视频、按标签找同一首歌、空文件夹、大文件、临时文件、损坏文件、扩展名错乱、清 EXIF、视频优化。
界面有三种：带 GTK 的老版 Czkawka、用 Slint 重写的新界面 Krokiet，还有一个安卓 APK（叫 cedinia，19.1MB）。我这次用命令行版，Windows 下就是一个 46.4MB 的单独 exe（48,670,208 字节），不吃运行库，扔进任意目录就能跑。
测试条件和实测数据
为了贴近日常情况，造了一个 825MB、1338 个文件的目录：400 张照片（300–700KB）另外复制一份到别处并统一改名，模拟换设备后重复导入；400 张互不相同的照片；60 段 3MB 视频，其中 20 段在子目录里又存了一份；40 个 3–6KB 的小图标，其中 15 个有副本；3 个大小都是 1MB、内容完全不同的 docx。
机器是 Ryzen 5 3550H（4 核 8 线程）、14GB 内存、SSD。命令一行就够：
czkawka_cli.exe dup -d "D:\photos" -f result.txt跑出来的数字：
- 默认（HASH + BLAKE3，8 线程）：两次分别 524ms 和 554ms，找到 420 个重复文件、420 组，标称可回收 252.97MiB
- 峰值内存：30.8MB
- 单线程
-T 1：1041ms，结果一模一样 - 哈希换 XXH3：326ms；换 CRC32：363ms，结果也一致
- 第二次跑（吃到哈希缓存）：254ms
为什么这么快？因为它先按文件大小分组，只有"大小撞车"的文件才会真的被打开读内容算哈希。825MB 里真正读过的只有约 520MB，那 400 张独立大小的照片一次都没被打开。所以 8 线程只比单线程快 2 倍也很正常——瓶颈在随机读盘，不在算哈希。
两个默认值会让你误判
8KB 以下的文件直接不看。 -m 最小文件大小默认是 8192 字节，小于这个值根本不进候选。我那 15 组重复小图标默认一个都没报；加上 -m 1 之后，结果从 420 组变成 435 组。图标、表情包、脚本、缩略图这类小文件重复多的话，这个参数必须手动改，否则你会以为"没重复"。
只按大小比会误报。 -s SIZE 只用文件大小判断，同一个目录它报的是 483 个文件、432.96MiB，比真实值多出 63 个文件、约 180MB。我特意造的三个 1MB 随机 docx 被它当成一组重复——它们内容毫无关系。省几十毫秒的代价是误删，要动真格删除就别用这个模式，老老实实走 HASH。
硬链接替换后的假象
-D HARD 可以把重复文件换成硬链接，两条路径都还能打开，但只占一份空间。实测这一套 252.97MiB 的重复，换完磁盘实际减少 259,856KB（253.8MiB），文件数量一个没少（1338 还是 1338），耗时 1.2 秒。
但紧接着再跑一次默认扫描，它会告诉你 Not found any duplicates——因为硬链接默认被跳过，要加 -L 才会重新列出来。我第一次看到这句话以为操作失败，跑去看磁盘空间才知道早就生效了。
硬链接比直接删好在哪：旧目录结构完整保留，照片管理器和 Jellyfin 这类媒体库不会因为路径消失而丢条目。限制也很明确：必须同一个分区，NTFS 支持；跨盘、移动硬盘、网盘挂载目录都不行，那种情况只能删或者移走。
我现在的用法
先用 -Q 空跑一遍看清单，把结果导出成 txt 逐条核对，确认没问题再执行。日常固定这么跑：
czkawka_cli.exe dup -d "D:\photos" -e "D:\photos\keep" -f D:\dup.txt -Q-e 用来排除不想动的目录，比如正在收拾的素材库。图形界面我更推荐 Krokiet，能直接预览相似图片；相似图片走的是感知哈希，这次没测——手头没有大批真照片，造出来的图不具代表性，不敢瞎写数字。
缓存这里有个我担心过的点：如果它只按路径和修改时间记哈希，那我用别的工具改过文件、又把时间戳改回去，它就会拿旧结果骗我。单独搭了个小实验——两个 3MB 相同文件，先跑一次建缓存，然后把其中一个内容整个换掉（大小不变）、把修改时间改回原值再跑，它没有再把两个文件当成重复。默认只有 257144 字节以上的文件才进哈希缓存，这也解释了第一次 524ms、第二次 254ms 的差别。想彻底排除干扰就加 -H，代价是每次都重新读盘。
它解决不了什么
几个边界得说清楚，免得白折腾：
- 网盘里的重复它看不见。只有把网盘挂成本地盘符才会被扫到，而且走网络读哈希很慢，不如先同步下来再扫。
- 跨盘比较要分次来。两块硬盘之间找重复，得把它们都加进
-d，内容要读两遍，时间基本翻倍。 - 相似视频要逐帧抽帧比对，比找重复文件慢一个量级，几十个片子就得等。
- 它替代不了备份策略。去重只是把同一份数据从三份压成一份，误删了照样没得救。
顺带一句对比：Everything 那种按文件名索引的工具，遇到"改名后的同一张照片"完全无能为力，两者解决的不是同一个问题，我机器上是都装着，各管一段。
说回实际效果：那套 825MB 的目录清完，实际省下 253.8MB，差不多三成。你们照片是只留一份，还是两套备份都留着？