Czkawka 开源贡献完整指南：文件清理工具新手的 5 条参与通道
【免费下载链接】czkawkaMulti functional app to find duplicates, empty folders, similar images etc.项目地址: https://gitcode.com/GitHub_Trending/cz/czkawka
Czkawka 是一款用 Rust 编写的免费开源工具，专为你找出磁盘里的重复文件、空文件夹、相似图片和相似视频，并安全地清理它们。它由一个共享的核心扫描库驱动，上面挂了命令行、桌面 GUI 和 Android 三套前端，因此适合不同背景的人从不同位置切入贡献。
认识 Czkawka：它解决什么问题，又缺哪些人手
先讲清楚这是什么。核心库 czkawka_core/ 负责真正的扫描算法——按文件名、大小或哈希查重、识别空目录、比对相似图像与视频、校验损坏文件等，特点是多线程、速度快、支持缓存。各前端只是把同一套能力用不同界面呈现出来。
参与它的理由有两面。对你：能在真实发布、跨 Linux/Windows/macOS 的项目里练 Rust、Slint、GTK 这几样东西，学到的代码规范是可迁移的；署名和致谢也会落在项目里。对项目：主维护者明确列出了他缺的东西——bug 修复、新功能、约 20 种语言里缺人工校对的翻译、面向各发行版与包管理器（deb、rpm、Homebrew、Chocolatey、Winget）的打包，以及帮用户搞懂工具的教程文章。
五分钟搭好开发环境：克隆、装工具、看懂目录
第一步把代码拉下来，仓库地址固定为：
git clone https://gitcode.com/GitHub_Trending/cz/czkawka cd czkawka环境上要装 Rust 工具链；项目用 just 作为任务运行器（一个替代 make 的小工具，命令都写在根目录的 justfile 里），翻译和脚本部分还要装 uv（Python 包管理器）。只改 Android 部分才需要额外配置 ANDROID_HOME 和 NDK。
目录结构速览，先认得这 8 个位置就够开工：
| 目录 | 作用 |
|---|---|
| czkawka_core/ | 核心扫描库，所有前端共用，对外也作为 crate 被第三方使用 |
| czkawka_cli/ | 命令行前端，适合自动化 |
| krokiet/ | 推荐的桌面 GUI，基于 Slint |
| czkawka_gui/ | 旧 GTK4 GUI，12.0 是最后一个版本，停更 |
| cedinia/ | Android 触控前端，基于 Slint |
| instructions/ | 各模块的使用与开发文档，含 FAQ 和翻译说明 |
| ci_tester/ | 集成测试 |
| misc/ | 打包、翻译、性能测试等辅助脚本 |
动手前务必读两份东西：根目录的 CLAUDE.md 是全体 Rust 代码的写作规范，各子目录的 AGENTS.md 是对应的局部补充；instructions/ 则是面向使用者的功能文档，改功能前先对着它确认预期行为。
五条参与通道：从报 Bug 到提交功能代码
按难度从低到高，每条都给你一个能直接上手的入口。
通道一：报 Bug。在项目的问题追踪器（Issue）里提交。写清四件事：复现步骤、你期望的行为、实际发生的行为、你的运行环境（操作系统、版本、用哪个前端）。维护者说这里堆了很多功能想法，但多数要么难实现、要么偏离项目方向，所以报问题时聚焦"和预期不符"的行为比提新想法更容易被采纳。
通道二：改文档。文档在 instructions/ 下，分 GUI、CLI、Core、GTK 和 FAQ 几份。修错别字、补使用示例、把某个报错说明白，都是实打实的贡献，且几乎不会被打回。
通道三：修代码。Bug 修复最被欢迎；做新功能前最好先与维护者沟通确认方向，复杂的特性建议先用外部脚本或独立小项目跑个可运行的原型，证明没有技术障碍。对应改动去具体 crate 的 src/ 目录里改。
通道四：翻译。界面用 Fluent 格式管理，翻译主要在项目的翻译平台上协作（入口见 Translations 说明）。新版本总会新增字符串，机器翻译填出来的部分仍需人工校对，这是长期缺口。
通道五：打包与分享案例。为不同发行版或包管理器维护安装包；或把你真实使用 Czkawka 的场景、配置写成文章或教程。后者门槛最低，却能让新用户更快上手。
写代码前该知道的协作约定：风格、测试与验证
项目的 Rust 规范集中在 CLAUDE.md，几条最影响你 PR 能否过的：
- 代码、注释、提交信息一律用英文；
- 格式化用
cargo +nightly fmt（稳定兼容再补一次cargo fmt），行宽上限 120； - 代码必须零 clippy 警告，要临时豁免某条 lint 必须用注释写明原因；
- 优先用
?、ok_or_else、map_err处理错误，unwrap()只出现在测试里，不要静默吞掉错误； - 函数保持短小，超过约 30 到 50 行就拆成命名清晰的小函数；单个源文件控制在 500 行以内，超了就拆模块；
- 用
log记录日志，命名要表达意图而非容器类型。
测试方面，项目要求尽可能用测试覆盖代码，写清楚assert_eq!并让输入贴近断言；能在合适处加 fuzzer、示例或基准测试会更好。
从本地改动到 PR 合并：提交、评审与社区交流
改完代码后，先本地验证再提交，这是维护者能合入你的前提。标准流程用有序列表走一遍：
- 把仓库 Fork 到你自己的账号；
- 克隆到自己机器，建一条特性分支，例如
git checkout -b my-new-feature； - 修改代码并提交，提交信息写英文、说清做了什么；
- 本地跑
just test（等价于对整个 workspace 跑cargo test）和just clip（clippy 自动修复）确认全绿； - 把分支推到你 Fork 的远端；
- 发起 Pull Request，描述改动、动机，并贴出你验证过的命令输出。
社区交流主要走三条线：在 Issue 里和功能、bug 讨论；参与别人 PR 的评审（哪怕只是提一条改进建议）；把踩过的坑和使用心得写出来分享。维护者会手动审阅并亲自测试每一个 PR，所以"能否讲清楚这段代码在做什么"比工具生成与否更关键。
命令与路径速查表，以及你如何被认可
把散在各处的操作信息聚到一张表，对照着用：
| 目的 | 命令 / 路径 |
|---|---|
| 完整构建（含 clippy 与测试） | just build_all |
| 跑全部单元测试 | just test |
| clippy 自动修复 | just clip |
| 运行某个二进制 | just run <二进制名> |
| 只跑被标记忽略的压力测试 | just ignored |
| 安装三个本地前端 | just install |
| 性能基准测试 | just bench |
| 各模块开发文档 | instructions/ |
| 全局 Rust 规范 | CLAUDE.md |
| 所有任务命令 | justfile |
关于被认可：README 里有一段专门感谢"以各种方式贡献的每一个人"，你的名字会留在项目致谢中。第一次贡献不必贪大——从改一个错别字、补一句注释、把一条报错提示写得更明确开始，选一个你感兴趣的 Issue，或直接从文档改起，迈出你开源贡献的第一步，往往比一次大改动更容易合入，也更早帮你摸清整套协作流程。
【免费下载链接】czkawkaMulti functional app to find duplicates, empty folders, similar images etc.项目地址: https://gitcode.com/GitHub_Trending/cz/czkawka
创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
