czkawka 深度解析：14 合 1 的 Rust 磁盘清理与重复文件检测工具

czkawka 深度解析：14 合 1 的 Rust 磁盘清理与重复文件检测工具

【免费下载链接】czkawkaMulti functional app to find duplicates, empty folders, similar images etc.项目地址: https://gitcode.com/GitHub_Trending/cz/czkawka

czkawka 是一套用 Rust 编写的磁盘清理与重复文件检测工具：一个核心库czkawka_core，四个前端，14 个内置工具，覆盖重复文件、空文件夹、相似图片、损坏文件与临时文件。名字在波兰语里是"打嗝"的意思。

磁盘清理为什么仍然难：14 个工具与 4 个前端

问题的起点很朴素：照片目录里存着三版同一张图，备份盘和项目目录之间散落着成百上千个相同文件，临时文件和空文件夹越积越多。人工翻找抓不全，而市面上的清理工具往往只做一件事，或者强依赖某个平台的图形环境。

czkawka 的选择是把算法全部收进独立的核心库czkawka_core，GUI、CLI、Android 前端都只是它的调用方。README 里列出 14 个工具：重复文件、空文件夹、大文件、空文件、临时文件、相似图片、相似视频、音乐重复、失效符号链接、损坏文件、扩展名不符、Exif 清除、视频优化、坏文件名。两条设计约束值得注意：程序完全不联网、不采集任何统计；代码"几乎 100% 无 unsafe"（README 原文），并运行在 Linux、Windows、macOS、FreeBSD、x86/ARM/RISC-V 和 Android 上。

重复文件检测的四级漏斗：从文件名到完整哈希

最吃性能的是重复检测。czkawka 不对每个文件直接算哈希，而是在czkawka_core/src/tools/duplicate/core.rs里把扫描拆成四级：

1. 按文件名分组，名字唯一的文件直接出局；
2. 按文件大小分组，同尺寸超过一个才保留；
3. 预哈希：只读每个文件的前 4 KB 算一个短哈希；
4. 完整哈希：仅当预哈希也撞车，才读取整个文件，用 BLAKE3、XXH3 或 CRC32 算最终值。

两个实现细节决定了它的速度。4 KB 的预读窗口是个常量：czkawka_core/src/tools/duplicate/mod.rs第 33 行写着PREHASHING_BUFFER_SIZE = 4 * 1024。这个量级在机械硬盘上也足够便宜，却能把内容不同的文件提前筛掉。另外，三级分组全部走 rayon 并行，每个工作线程持有独立的读取缓冲区（thread-local），大分组用with_max_len限制并发任务数，避免内存尖峰。

为什么是"预哈希 + 完整哈希"，而不是直接哈希到底

直接哈希最省事，但磁盘 I/O 与文件总大小成正比。有了漏斗之后，绝大多数文件在前两级就被排除，只有极少数走到完整读文件那一步。项目在czkawka_core/benches/hash_calculation_benchmark.rs里用 criterion 对 16 MiB 测试文件做微基准，对比不同缓冲区大小与哈希实现——仓库提供的是基准工具本身，没有公布官方跑分，所以本文不引用任何未经证实的秒数。

第二次扫描几乎免费：缓存怎么管

每个算出的预哈希都会写进本地缓存。下次扫描时，prehash_load_cache_at_start先读缓存，把待查文件拆成"缓存已有"和"需要重算"两份，只有后者碰磁盘。缓存记录只有在文件大小没变时才被复用，逻辑在czkawka_core/src/common/cache.rs的load_cache_from_file_generalized_by_path里：尺寸对不上就整条作废重算。

缓存失效与容量保护

缓存文件带版本号（如CACHE_DUPLICATE_VERSION），格式不兼容时自动整体重建。序列化走 bincode，内存上限设为 8 GiB，防止一次超大扫描吃光内存。默认每 7 天自动清理一次缓存；小于阈值的文件不写入缓存，因为小文件缓存的维护开销比重算还高。12.0 版本曾主动让旧预哈希缓存整体失效（见Changelog.md）——宁可一次性重扫，也不维护双格式兼容，这笔账算得清楚。

从 GTK 到 Slint：前端为什么重写

四个前端共享同一个核心：Czkawka（GTK 4）、Krokiet（Slint）、Cedinia（Android，Slint）加命令行版。README 写得很直接：GTK 版 12.0 是最后一个发布版本，新用户建议切换到 Krokiet。

重写动机在krokiet/README.md里逐条列了：GTK 在 Windows 和 macOS 上表现差、偶发 bug；交叉编译基本只能靠 Linux Docker 容器；动态链接库导致"下载完还缺依赖"。Krokiet 把一切打进单个二进制，无强制运行时依赖，只有相似视频工具需要系统里的 ffmpeg。

Cedinia 用同一套 Slint 技术移植到 Android，做触控适配；因平台缺 ffmpeg，视频类工具在其上不可用（README 注释说明）。

实际使用：CLI 扫描命令与功能边界

命令行是自动化的最佳入口，czkawka_cli/README.md的示例可以直接照搬：

# 扫描重复文件: 排除指定目录, 用哈希判定, 结果写入文件 czkawka dup -d /home/rafal -e /home/rafal/Obrazy -s hash -f results.txt # 空文件夹与大文件扫描 czkawka empty-folders -d /home/rafal/rr -f results.txt czkawka big -d /home/rafal -n 25 -x VIDEO -f results.txt

-d指定扫描根目录，-e排除路径，-x按类型（IMAGE/VIDEO 等）收窄范围，-s hash强制走完整哈希判定，-f把结果落到文件里，方便脚本接力处理。

想看某个工具的完整参数：

czkawka_cli --help czkawka_cli dup --help

每个工具的帮助都内置在二进制里，离线可查。

自己编译 GUI 也很轻：

cargo install krokiet --locked # 或开启额外图片格式支持: HEIF / RAW / AVIF cargo build --release --bin krokiet --features "heif,libraw,libavif"

第一条装出即用的发布版；第二条在需要扫 HEIC、RAW、AVIF 时才要加，对应原生库的安装方法见krokiet/README.md。

同类工具的功能覆盖差异（数据来自主 README 的官方对比表）：

取舍各不相同：FSlint 有已装软件包检查、文件名冲突检查等 czkawka 没有的工具；DupeGuru 的自定义对比选项更多。czkawka 的胜面在于工具广度、多平台覆盖和缓存带来的重复扫描成本。

速度来自哪里，下一步往哪走

速度由三层构成：rayon 多线程漏斗扫描、预哈希缓存（README 的官方表述是"第二次及以后的扫描应该快得多"）、bincode 二进制缓存的读写。12.0.1 版本给图片加载加了 500 MB 尺寸上限，防止异常大文件触发内存耗尽；同时给 Krokiet 加了"关于/诊断"面板，可以检查 HEIF、LibRAW、AVIF、FFmpeg 等可选依赖的运行时状态（Changelog.md12.0.1 条目）。

核心库也在向外溢出：czkawka_core作为独立 crate 被 czkawka-tauri 等第三方项目复用，PyPI 上有 Python 绑定（README "Projects using Czkawka" 一节）。维护方向已经写明：GTK 前端停用，视频优化器、Bad Names、Exif 清除等新特性只落在 Krokiet 和 Cedinia 上。对个人用户，它是免费的磁盘清理与重复文件检测工具；对想在自己产品里内嵌文件分析能力的团队，那个核心库才是更完整的入口。

【免费下载链接】czkawkaMulti functional app to find duplicates, empty folders, similar images etc.项目地址: https://gitcode.com/GitHub_Trending/cz/czkawka