最准的是find -type f -printf '%s %p\n' | sort -nr | head -10，因直接读inode大小、无locale干扰、速度快；du -ah次之但含目录和磁盘占用偏差；两者均须加2>/dev/null避权限错误。
直接用 find + sort 组合最准，du -ah 排序次之；但两者都必须加 2>/dev/null，否则权限错误会中断或污染结果。
为什么不用 du -sh /* | sort -rh | head -10 直接扫根目录？
这个命令只列目录，不列文件——-s 会让 du 跳过子项汇总，-h 又不带 -a，所以根本看不到单个大文件（比如 /var/log/syslog.1 或 /home/user/archive.tar.gz）。它实际找的是“最大的 10 个目录”，不是“最大的 10 个文件”。
常见错误现象：执行后输出全是 4.2G /var、3.1G /usr 这类行，但你真正想找的日志文件或 core dump 完全没出现。
- 要查文件，必须加
-a（du -ah）或换用find -type f -
du统计的是磁盘占用量，硬链接、稀疏文件、压缩文件系统（如 btrfs 的透明压缩）会导致数值与ls -l显示的逻辑大小不一致 - 在中文 locale 下，
sort -hr可能排序错乱（例如999M排在1.2G前面），稳妥做法是转字节数：du -ab / 2>/dev/null | sort -nr | head -n 10
find -type f -printf '%s %p\n' | sort -nr | head -10 是最轻量可靠的起点
这个组合绕过 du 的递归开销和单位解析，直接读取 inode 的 st_size 字段，速度快、结果稳定、无 locale 干扰。
在无 root/sudo 权限的环境（云容器、VPS、隔离主机）中安装并配置 OpenClaw 浏览器工具的 headless Chrome。适用场景：...
使用场景：需要快速拿到一批候选大文件路径，后续再人工确认是否可删。
-
-printf '%s %p\n'输出“字节数+空格+完整路径”，sort -nr按纯数字逆序排 - 务必加
-xdev防跨文件系统，避免卡在/proc、/sys、/mnt等挂载点：find / -xdev -type f -printf '%s %p\n' 2>/dev/null | sort -nr | head -10 - 如果只想看大于 500MB 的文件，优先用
-size +500M过滤，比排序快一个数量级：find / -xdev -type f -size +500M -printf '%s %p\n' 2>/dev/null | sort -nr | head -10 -
2>/dev/null不可省略——没有它，/root、/boot/efi等路径的权限拒绝会打断管道，导致结果缺失
当 find -printf 不可用（如旧版 macOS / BusyBox），改用 stat + awk
某些系统（特别是 Alpine Linux 或嵌入式环境）的 find 不支持 -printf，这时用 stat -c '%s %n' 替代，但要注意字段顺序和错误处理。
参数差异：stat -c 是 GNU coreutils 特有，BSD/macOS 用 stat -f '%z %N'；若两者都不在，退回到 ls -l + awk 提取第五列，但需注意列对齐问题。
- GNU 系统安全写法：
find / -xdev -type f -exec stat -c '%s %n' {} \; 2>/dev/null | sort -nr | head -10 - 为防
stat报错中断，建议包裹在sh -c中并忽略单条失败：find / -xdev -type f -exec sh -c 'stat -c "%s %n" "$1" 2>/dev/null' _ {} \; | sort -nr | head -10 - 如果输出里混入了类似
stat: cannot read的错误行，说明2>/dev/null没加对位置——它必须放在find整体之后，不能只放在stat后面
真正容易被忽略的点是：**不要一上来就扫 /**。先 df -h 看哪个分区 Use% >90%，再针对那个挂载点查（比如 /dev/vda1 对应 /，/dev/vdb1 对应 /data）。全盘扫描不仅慢，还可能触发 IO 限速或 OOM killer —— 尤其在低配 VPS 上，find / 卡住 3 分钟不是意外，而是常态。
