dust 实测：扫 5020 个文件 272 毫秒｜实测库

dust 是一个命令行磁盘占用查看器，主程序 2882048 字节。给它一个目录，它按体积从大到小列出子目录，每条右边画一根占比条。

它替掉的是「一层层点进属性看大小」这一步。Windows 资源管理器只能算当前文件夹，往下哪一层吃掉空间要靠人手动展开，dust 一次把整棵树按体积排开。

这次扫了两个真实目录：一个 5020 个文件的测试树，量了带色与不带色的耗时和输出字节；另一个 634 MiB 的素材目录，用来截屏确认三列排版。

解压出来三个文件

官方 zip 1087936 字节，解开只有 3 个条目，主程序加 LICENSE 与 README。没有安装向导，不写注册表。

版本命令连跑三次

# 三次耗时 163 / 132 / 121 毫秒
dust --version
Dust 1.2.6

第一行 163 毫秒是杀毒软件在扫新解压的 exe，后两次 132 和 121 毫秒才是它自己的启动开销。

它不读配置文件

2882048 字节里没有默认配置，参数全靠命令行。-n 控制显示几条，-d 控制往下钻几层，--no-colors 关掉颜色。

扫 5020 个文件 248 毫秒

测试树是 100 个目录、每目录 50 个文件，合计 5020 个文件 96852 字节。带默认样式跑三次是 757 / 272 / 248 毫秒，第一轮冷缓存明显慢。

颜色和占比条占了 1547 字节

同一份输出，关掉颜色和条形图只剩 534 字节，带样式是 2081 字节，差 1547 字节。21 行数据摊下来，每行多出来七十多个字符，都是转义序列和方块字符。

和 os.walk 对一遍

同一棵树用 Python 的 os.walk 加 getsize 遍历，三次是 310 / 286 / 299 毫秒。dust 中位 272 毫秒，快 27 毫秒，两者都在同一量级。

# dust 中位 272 毫秒
dust D:\wb_cache\b4\tree -n 20
# os.walk 中位 299 毫秒
python -c "import os;sum(os.path.getsize(os.path.join(d,f)) for d,_,fs in os.walk('tree') for f in fs)"

三列怎么读

截图那次扫的是 634 MiB 的素材目录，12 行。左边一列体积，中间是带缩进的目录树，右边一列百分比，中间夹一根横条表示占比。

体积单位是二进制的

817Ki 是 836608 字节，不是 817000。对着资源管理器的数字会差 2.4%，看大文件时容易对不上，习惯一下就行。

-d 控制钻几层

加 -d 1 只展开一层，输出从二十多行压到 12 行，屏幕上不用滚动就能看完。不带这个参数它按体积挑，深目录容易把屏占满。

装之前先确认三件事

解压即用，没有安装步骤。要确认的是终端支不支持转义序列，以及路径里有中文会不会出错。

控制台要开虚终端

cmd 里直接跑，输出会是一串 ←[90m 开头的字符，颜色不生效。这个现象不是程序坏了，是控制台没启用转义序列解析。

它只读不写

dust 不删任何东西，参数里没有删除选项。想让 dust 帮你腾空间做不到，它只负责把数字摊开给人看。

三个真会踩的地方

第一次跑特别慢

冷缓存那轮 757 毫秒，热缓存 248 毫秒，差三倍。刚开机或者刚挂载的磁盘，第一次跑要按三倍时间预期。

默认行数会把屏占满

不带 -n 时它按体积挑，深目录能列出几十行。终端只有 30 行时，前面的结果被顶上去看不到，加 -n 12 更实用。

权限不足的目录被静默跳过

扫系统盘时，没有权限的子目录不会报错，直接从总量里消失。总数比资源管理器小一截时，先怀疑权限，不是程序算错。

什么场景值得上

找「磁盘怎么满了」这件事最合适。634 MiB 的素材目录一次列出 12 行，哪个子目录吃掉大半一眼看得出，比一层层点属性快。

反过来，只想知道单个文件夹多大的人用不上。资源管理器右键看属性已经够，装一个 2882048 字节的 exe 换不来多少。