disktree 爆火全记录：平均 13.6 星/小时、1 天 2k 星，GitHub 热榜新贵的速度曲线
【免费下载链接】disktreeA treemap for finding and removing what fills your disk, for Omarchy. Rust + GPUI.项目地址: https://gitcode.com/gh_mirrors/di/disktree
磁盘空间清理是一个被反复做过的品类：终端里有du、dust、dua、ncdu，桌面端有 Baobab、WizTree、OmniDiskSweeper。这个赛道几乎不产生"新闻"。直到 2026 年 10 月，一款用 Rust + GPUI 写成的树图（treemap）磁盘清理工具 disktree 以平均 13.6 星/小时、单日 2k 星的速度冲上 GitHub 热榜——2.5k stars、160 forks、122 commits，最新版本 0.11.0 于 2026 年 10 月 4 日发布。星标暴涨只是表象，真正值得拆解的是三个问题：它凭什么在两天内走完同类工具数年的路？它的产品力能否承接住这波流量？以及这条速度曲线回落之后，还剩什么？
热度起点：一场有据可查的"新贵"登顶
"平均 13.6 星/小时、1 天 2k 星"来自 GitHub 趋势榜（gh_search）的观测口径，两个数字并不矛盾，而是同一曲线的不同切片：单日 2k 星折算约 83 星/小时，是 13.6 的 6 倍——13.6/h 覆盖了从蓄力到峰值再到回落的完整窗口，2k/天则大概率对应 Trending 上榜后的爆发首日。
把观测数字与可核验锚点对齐，这条曲线是扎实的：
- 规模：截至 2026 年 10 月上旬，2.5k stars、160 forks、8 watchers；
- 迭代密度：122 commits、14 个 PR、13 个 issue，最新发布 v0.11.0（2026-10-04）；
- 生态卡位：仓库定位"为 Omarchy 而生"，发布即进入 AUR（源码构建与预编译二进制双包），Arch/Omarchy 用户群体是第一波基本盘；
- 中文社区的镜像式跟进：2026-09-27 至 09-29 三天内，CSDN 密集出现十余篇 disktree 深度拆解——Rayon 并行扫描、目录分类引擎、安全删除规则、Squarified Treemap 算法、快捷键清单、Windows NTFS 原理、Worth a look 洞察模块，几乎覆盖了仓库每一个核心模块。这种"内容供给侧"的集中爆发，是热度向开发人群渗透的明确信号：星标代表围观，拆解文章代表有人真正在读懂它。
热度不是凭空降落的。disktree 在公开前就把"别人要花一周调研的东西"全部写进了仓库：README 详尽到每个平台的行为差异，代码注释解释每一个非显然的工程决策。当流量到来时，它已经是一份可以被任何博主逐模块拆解的技术文本。
增速拆解：13.6 星/小时的成色
把 disktree 放进同类的历史坐标里，速度对比才显出分量。终端工具 dust（"du + rust"）2018 年创建，累计 633 commits、12.5k stars，走了八年的长尾积累曲线；dua、ncdu、Baobab 等同样是多年口碑型项目。disktree 用爆发窗口追平了它们数年才获得的关注密度。
凭什么？三个可验证的事实：
第一，它补的是一个"视觉化清理"的空白，而不是重复一个功能。dust 解决了"快速看出哪个目录大"，但输出停在终端文本；disktree 把它升级为 GPUI 渲染的彩色树图——目录按真实磁盘占用切成嵌套马赛克，颜色编码数据类型，斜纹标注可回收空间，侧栏实时显示"标记后能腾出多少"。清理工具最大的用户痛点从来不是"测不准"，而是"看不懂、不敢删"，树图把这两个问题一次性视觉化。这是 CLI 与 GUI 两条完全不同的获客路径。
第二，它站在了成熟架构的肩膀上。扫描引擎没有从零发明——crates/disktree-core/src/scan.rs 的模块注释第一句就写明"shape follows dust"，直接继承 dust 被验证过的并行扫描骨架（rayon scope、目录完成计数、自底向上聚合），再在其上叠加无锁进度、协作式取消、扫描记忆化等 GUI 场景需要的增量。站在被百万次执行验证过的设计上，意味着少踩坑、快发布。
第三，发布物是"三端齐备"的。Linux（tar.gz + AUR）、macOS（签名公证支持）、Windows（含直读 NTFS 主文件表的 MFT 模式）三条发布线同时就绪，单日 2k 星的流量来自全平台用户，而不是某个单一发行版的圈层。
扫描快、删得稳：产品力如何承接热度
流量只会放大一个项目的优点和缺点。disktree 能接住这波关注，靠的是源码里可以逐行验证的三件事：扫得快、认得准、删得稳。
快：O(1) 递归深度的并行扫描
scan.rs 用rayon::scope把每个根目录摊平为平铺任务，递归深度恒定 O(1)，再深的目录树也不会爆栈；每个目录是一个PendingDir，持有原子完成计数器与+1哨兵——只有当自己的扫描与所有子目录任务全部结束时目录才被构建，从机制上杜绝"提前上抛导致整棵子树静默丢失"的竞态。进度条用纯 relaxed 原子计数，UI 读取允许过期的快照，扫描过程零锁竞争。
两处细节把"快"推到极致：
- 记忆化拓宽：
Known子树结构允许把已扫描的~整棵交给更宽的扫描复用（scan_blocking中的classify_dir命中已知路径时直接取树不重走）。因此从家目录一键扩展为整盘扫描，只需读家目录之外的新区域——README 记载"从~到/只需几秒而非完整重扫"。 - Windows 上的 MFT 直读：crates/disktree-core/src/mft.rs 在管理员权限下不再遍历目录树，而是单遍读 NTFS 主文件表。README 记录的实测：400 万文件的
C:\整盘，disktree 约 3.4 秒，WizTree 约 11.2 秒，普通遍历约 20 秒——比公认最快的 WizTree 快一个量级，且连 System Volume Information 这类遍历被拒的目录也能计入。
准：名字驱动的分类与"可回收"判定
树图的颜色不是装饰，crates/disktree-core/src/classify.rs 实现了 8 类数据类型识别（代码、Agent 暂存、工具链、同步文件、Git、媒体、文档、缓存）与 9 种可回收空间判定（可再生缓存、同步历史、包存储、构建产物、可重装依赖、沙箱层、快照、回收站、临时文件）。
识别采用三段式策略：目录名查表 → Git 仓库形状检测 → 内容启发式归类，未知目录继承父类，顶级未知目录取最大可识别子目录的类型。判定可回收时引入邻居检查：target只有旁边躺着Cargo.toml才判定为构建产物，node_modules只有旁边有package.json才判定为可重装依赖——名字太常见就不能单独信任，必须由语境背书。这是"误删恐惧"的第一道防线。
insights.rs 的 "Worth a look" 模块则是第二道：它只列出三类"大概率可以清"的候选——可回收空间、Agent worktree 目录、超过 30 天未写入的tries/experiments实验目录，并以 64 MiB 为下限做剪枝，让百万级文件的扫描只需检查几千个目录就能给出清单。
稳：五重守卫的安全删除
清理工具最大的产品风险是删除本身。crates/disktree-core/src/removal.rs 用 24 项系统树黑名单（/usr、/etc、/nix/store、Homebrew 前缀等，跨平台统一一份列表）、挂载点拦截、家目录的三重身份校验（拼写、真实路径、设备+inode）、Windows Win32 名称陷阱检测（NUL、COM1、尾随点空格这类"会被系统读成另一个名字"的文件）以及"路径永不经过 shell"五类规则，把删除严格限定在用户标记范围内。README 直言"一个叫-rf的文件就只是文件"。
交互流程是三段式的：标记（Space）→ 审查（Review 列表逐条确认）→ 执行（移入回收站或永久删除，永久删除必须二次确认）。执行完毕后自动重扫，屏幕数字与磁盘真实状态对齐——"承诺的回收量"用statvfs前后差值实测，而不是预估。
工程纵深：为什么敢让用户删数据
敢把删除权限交给用户，背后是罕见的工程自律。根目录 Cargo.toml 把clippy::all与clippy::pedantic全部设为错误，每条豁免都写明理由挂在代码库中；AGENTS.md 记录了 9 条架构不变量（尺寸只能来自st_blocks × 512、总量只能推导不能跟踪、目录必须在全部子任务完成后才构建、标记按绝对路径持久化……），并配套真实窗口测试——crates/disktree-app/src/tests.rs 会真画帧、真按键，其中一条用例就是标记目录、确认删除、验证文件消失而相邻文件完好。删除逻辑不是"看起来对"，是被测试锁死的对。
热度持续性判断：观测指标与回落风险信号
爆发之后的第一个问题是：星标曲线还能不能续？
支撑正向预期的指标：122 commits 与 v0.11.0 表明这是高频迭代的项目，而非"发完即走"的玩具；AUR 双包与三端发布物降低了留存门槛；社区内容（CSDN 拆解潮）说明已经形成"讲解—使用—再讲解"的内容飞轮；README 的完整度意味着新用户的第一体验是顺畅的。只要 release 节奏保持，2.5k 星的基本盘足以支撑二次上榜。
必须正视的回落风险：其一，这是典型的单作者驱动项目，160 forks 之下贡献者密度极低，爆发期的 issue/PR 涌入（当前 13 issues / 14 PR）最终会转化为维护压力——工具类项目最怕的不是没人用，而是作者精力被涨潮吞掉；其二，磁盘清理是"用完即走"的高频卸载型工具，留存天然弱于编辑器、浏览器这类常驻软件，星标是"认可"而非"日活"；其三，13.6/h 与 2k/天的爆发窗口依赖 Trending 榜单的曝光杠杆，榜单撤下后回归常态增速是数学必然；其四，dust、dua、ncdu 等成熟竞品随时可能跟进 GUI 化，差异化窗口不会永远敞开。
因此，判断 disktree 热度是否可持续，盯的应该是三个可观测的替代指标：issue 从涌入走向解决的速度（维护健康度）、PR 中非作者贡献的比例（社区化程度）、以及下一次 release 的间隔（迭代节奏）。星标曲线是放大器，这三者才是本金。以 0.11.0 的发布节奏和仓库里那份把每个工程决策都写成注释的认真劲来看，这个项目至少已经把"爆火"这件事，当作一次值得长期经营的机会——而不是一个需要消费掉的流量事件。
【免费下载链接】disktreeA treemap for finding and removing what fills your disk, for Omarchy. Rust + GPUI.项目地址: https://gitcode.com/gh_mirrors/di/disktree
创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
