gdu 5.38.0 是磁盘用量分析器，Windows 版是单个 23138304 字节的 exe，压缩包 9027701 字节，扫描 1.1 GiB 的目录只要 219 毫秒。
它要解决的是：磁盘满了以后，要知道是哪个文件夹吃掉的空间。资源管理器只能一层层点进去看属性，看不到全貌。
这次量了三件事：程序自身的启动开销、两种输出模式在一个 20 MB 小目录和一个 1.1 GiB 大目录上的耗时，以及交互界面实际列出的条目数。
一个 23138304 字节的 exe
压缩包 9027701 字节，解压出来就是一个 exe。Go 编译的程序把运行时全部静态链接进去，所以不需要任何 DLL。
| 项 | 值 | 说明 |
|---|---|---|
| 压缩包 | 9027701 字节 | gdu_windows_amd64.exe.zip |
| gdu_windows_amd64.exe | 23138304 字节 | 单文件，无依赖 |
| 版本 | 5.38.0 | --version 输出 83 字节 |
| 启动开销 | 191 毫秒 | 五次 --version 的中位 |
23138304 字节里没有界面框架
它画的是一个纯文本框，没有 GTK 也没有 Electron。体积来自 Go 运行时与 TUI 渲染库，剩下的是核心代码。
191 毫秒是它的成本底线
跑一次 --version 和扫一个目录的耗时相差很小，说明在这个体量上程序加载就是主要成本，真正的目录遍历花不了多少时间。
扫 20 MB 用 201 毫秒
第一个测试目录是 10000 个文件、20857118 字节。非交互模式列出全部条目用 201 毫秒，只算总用量用 194 毫秒。
| 模式 | 目录 | 耗时 | 输出 |
|---|---|---|---|
| -n 全量 | 10000 个文件 | 201 ms | 406 字节 |
| -n --summarize | 10000 个文件 | 194 ms | 19.9 MiB tree |
两模之间只差 7 毫秒
全量模式要把每一层目录都算出来打印，汇总模式只算总数。7 毫秒的差距说明计算量本来就不大，主要时间在遍历目录项。
19.9 MiB 和 20857118 字节对得上
20857118 除以 1024 再除以 1024 等于 19.89，所以显示 19.9 MiB。它用的是 1024 进制，和资源管理器显示的 MB 会有约 5% 的差。
扫 1.1 GiB 只用 219 毫秒
第二个测试目录里有 209 MB 的视频文件，总用量 1173479906 字节。汇总模式 219 毫秒，全量模式 212 毫秒。
| 目录 | 总字节 | 汇总模式 | 全量模式 |
|---|---|---|---|
| tree | 20857118 | 194 ms | 201 ms |
| pk5 | 1173479906 | 219 ms | 212 ms |
体积涨 56 倍，耗时只涨 25 毫秒
20857118 到 1173479906 是 56 倍，耗时从 194 涨到 219 毫秒。它读的是目录项里的文件大小，不打开文件读内容，所以体积不影响速度。
决定耗时的是文件数量
两个目录的文件数都在一万左右，所以耗时接近。真正拖慢扫描的是几十万个小文件，而不是几个大文件。
界面列了 12881 个条目
交互模式在这个 1.1 GiB 目录上扫出 12881 个条目，按体积从大到小排，每行一个横条加体积加名字。
| 位置 | 内容 |
|---|---|
| 顶部 | 提示：方向键导航，按 ? 看帮助 |
| 主体 | 条形图 + 体积 + 文件名，目录名以斜杠结尾 |
| 底部状态栏 | Total disk usage 1.1 GiB、Apparent size 1.1 GiB、Items 12881 |
最大的一项吃掉近两成体积
排第一的文件 199.6 MiB，条形几乎占满整行。第二名是 181.8 MiB 的目录，第三名 144.8 MiB 的另一个视频。三项加起来是 526.2 MiB，接近全盘的一半。
目录名带斜杠是唯一区分
列表里文件和目录混排，目录在名字前加一个斜杠，比如 /PotPlayer、/zellij。看名字时要注意这个符号，否则会把目录当成文件。
Total disk usage 与 Apparent size
状态栏同时给两个数：Total disk usage 和 Apparent size。这次两个都是 1.1 GiB，说明没有稀疏文件或硬链接导致的偏差。
| 指标 | 含义 |
|---|---|
| Total disk usage | 实际占用的磁盘块 |
| Apparent size | 文件大小之和 |
| Items | 条目总数，这里 12881 |
两个数不一致时要看前者
大量小文件会让磁盘占用大于文件大小之和，因为每个文件都要占满最小的块。要清空间时以 Total disk usage 为准。
Items 包含目录
12881 是文件加目录的总数，不是一个目录下 12881 个文件。排查「哪个目录文件多」时要考虑这一点。
几个真踩过的点
下面三条在这次测试里真实出现，附当时的处理方式。
| 现象 | 原因 | 处理 |
|---|---|---|
| 直接跑 exe 没有任何输出 | 不带参数时进交互模式，需要一个终端窗口 | 加 -n 走非交互，或先开 cmd 再跑 |
| 脚本里读不到结果 | 交互模式的界面是刷屏的，不是输出流 | 用 -n 加 --summarize 只取一行总量 |
| 和资源管理器的数字差 5% | 它用 1024 进制，资源管理器用 1000 进制 | 按 MiB 读，别当成 MB |
没有终端就跑不起来
双击 exe 会闪退，因为它要接管整个屏幕。要么在 cmd 里启动，要么加 -n 让它只打印文本。
脚本要用非交互模式
交互界面靠转义序列重画每一帧，重定向到文件后是一堆控制字符。要解析数字只能用 -n。
什么场景值得上
想知道「这块盘到底被什么占满」，又不想一层层点属性时，它把整棵树按体积排成一张表。
| 场景 | 合适度 | 说明 |
|---|---|---|
| 找占空间的大目录 | 高 | 1.1 GiB 目录 219 毫秒出结果 |
| 服务器上没有图形界面 | 高 | 单个 exe，纯终端 |
| 脚本里统计目录用量 | 高 | -n --summarize 输出一行 |
| 几十万小文件的目录 | 中 | 耗时随文件数涨，不随体积涨 |
它不删文件
只显示用量，删除要自己去对应目录操作。这个分工让它比清理工具安全，也意味着它不能直接腾出空间。
授权与费用
MIT 许可，个人和商业环境都不收费。源码在 GitHub 上，主要语言 Go，release 覆盖 Windows、macOS、Linux 三平台。
