duls：du+ls 混合体，90.4% 覆盖率下的反直觉输出格式与极端文件大小分布

工程基础：Go 实现、5 次提交与 90.4% 测试覆盖率

在 HN 刷到 duls 的时候，帖子只有 1 分、0 条评论 来源：HH]。但仓库 README 第一行写着 "Test coverage: 90.4% 😍👌" 来源：DULS]，这个数字在个人工具项目里偏高。作者是 Go 开发者，仓库有 go.mod、go.sum 和 .github/workflows CI 配置，说明走了完整的 Go 工具链 来源：DULS]。

整个仓库只有 5 次提交，目录结构分 architecture/、cmd/duls/、internal/、worklogs/ 四块。worklogs 下有个 2026-10-24-scan-redesign，暗示扫描算法在某天被推倒重写 来源：DULS]。仓库还带了 AGENTS.md 和 Makefile，表明有自动化构建流程 来源：DULS]。安装一条 curl 管道就能跑完，或者 go install 从源码构建 来源：DULS]。

量化输出解剖：957 个文件、1.6 GB 与极端分布

README 给的示例输出扫了大约 957 个文件、1.6 GB 空间 来源：DULS]。文件类型分布高度集中，.jpg 占 65%、.png 占 29%、无扩展名占 2%、.pdf 占 1%，.jpeg 和 .webp 均为 0%，另有 +17 种未展示 来源：DULS]。这个比例说明扫描目标大概率是个人工作目录，照片占绝对主导。

目录间的体量差异更极端。Pictures 目录 910 个文件占 1.0 GB，贡献了 64% 的总量 来源：DULS]。Downloads 只有 23 个文件却塞了 574.4 MB，占 36%，单文件均量约 25 MB 来源：DULS]。

另一端 Documents 文件数量最多，大约 4.1k 个，体积却只有 154.2 MB，不到 10% 来源：DULS]。Recordings 4 个文件总共 533.0 kB，不到 1%，跟 Downloads 差了千倍量级 来源：DULS]。这种分布模式在真实个人目录里很常见，照片多但单个不大，下载目录文件少但单个动辄几十 MB。

设计取舍：混合哲学、反直觉格式与极低社区关注

duls 的定位写在标题里，A bit of du, a bit of ls 来源：DULS]。它混合了目录遍历和文件列表两种视角。README 里的描述是 "Focusing on whats important, within when you want it"，按需渐进呈现，不会一次性倒出全部内容 来源：DULS]。

输出格式有一个反直觉的设计。README 标注了 "entry files size share largest inside, without a row of its own" 来源：DULS]。意思是最大文件不独占一行，嵌在所属目录的行内展示。比如 Downloads 行里直接跟了 chatgpt_amd64.deb 和 Antigravity.tar.gz，不需要额外跳一层看详情 来源：DULS]。

但这个想法在 HN 上几乎没有引起任何反应。1 分、0 条评论，工程投入和社区关注度严重错位 来源：HH]。worklogs 里的 scan-redesign 说明作者确实在迭代，但分发渠道似乎还没打通。

多源对比：工程自述与社区信号的分歧

GitHub 侧的自述强调 "Hyper-optimized" 和 90.4% 覆盖率，定位是高性能专业工具 来源：DULS]。HN 帖的数据面却是另一番景象，1 point / 0 comments，没有任何社区验证 来源：HH]。README 展示了完整的示例输出（957 文件、1.6 GB 场景），但 HN 帖没有附截图或实测数据。

安装脚本 setup.sh 独立存在于 raw.githubusercontent.com，一行 curl 就能装 来源：DULS]。但 HN 帖甚至没链接这个脚本，潜在用户想试用还得自己去 GitHub 翻 README 来源：HH]。

我不确定这个项目最终会不会有人用。5 次提交、90.4% 覆盖率、完整的 CI 和 Makefile，这些工程指标的投入是真实的。但一个 CLI 工具的生命周期取决于能否触达用户。测试覆盖率再高，没人知道就等于不存在。duls 目前卡在了中间状态，代码质量到位了，分发和传播还没跟上。

原文：

Show HN: Duls – A bit of du, a bit of ls. Best of both · 来源：Hacker News

作者：itfan123 值班编辑 · 发布于 2026年10月25日