真正能用的命令必须带 -type f 和 -xdev；正确写法是 sudo find / -xdev -type f -size +1g 2>/dev/null，否则会匹配虚拟文件、跨挂载点卡死或单位无效。
find 是最直接的命令，但不加关键参数会返回一堆假结果——比如把 /proc/kcore（虚拟文件，显示几百 GB 却不占磁盘）或目录本身（-size 对目录只算元数据块数）也算进去。真正能用的命令必须带 -type f 和 -xdev。
为什么 find / -size +1G 总是卡住还报错？
这是最常踩的坑。错误原因很具体：
-
-size默认对所有文件系统节点生效，不加-type f就会匹配目录、符号链接、设备文件，甚至/sys和/proc下的虚拟条目 - 不加
-xdev会跨挂载点搜索，碰到 NFS、Docker volume 或未就绪的 USB 设备时卡死或报No such file or directory - 单位写成
+1GB或+1000MB是无效的：B不是合法后缀，GNU find 会静默忽略单位，退回到按 512 字节块计算，结果偏差百倍
正确写法：sudo find / -xdev -type f -size +1G 2>/dev/null
find 找不到“真·最大文件”？试试 du + sort
find -size 只筛单个文件逻辑大小，但磁盘实际占用受硬链接、稀疏文件、日志轮转影响。比如一个被 5 个进程同时写入的日志，ls -l 显示 2GB，du 可能只占 800MB；反过来，/var/lib/docker/overlay2 目录下一堆小文件，加起来吃掉 30GB，find -size 根本扫不到。
可靠做法是让 du 统计真实磁盘块占用，再排序：
- 查整个根目录下前 10 大项（含目录和文件）：
du -ahx / 2>/dev/null | sort -hr | head -n 10 - 只看文件（跳过目录）：
find /var -xdev -type f -print0 | xargs -0 du -h | sort -hr | head -n 10 -
-hr中的h必须有——没它就按字典序排，999M会排在1.2G前面
删之前必须确认：文件是否还在被进程占用？
直接 rm -f 一个正在被 rsyslogd 或 Java 应用写入的日志文件，空间不会释放。inode 还被进程持有着，df 看不到变化。
- 先查占用：
lsof +L1 | grep 'deleted'（找已删除但仍被打开的文件），或针对具体路径：lsof /var/log/syslog.1 - 真要清空而非删除：
> /var/log/syslog.1比truncate -s 0更通用，不依赖truncate命令是否存在 - 删完别忘了
sync，尤其在 RAID 卡或物理机上，避免缓存延迟导致df显示不准
交互式排查推荐 ncdu，但别一上来就扫 /
ncdu 界面友好，但默认行为很危险：
- 首次运行
ncdu /可能卡死 10 分钟以上，且会递归扫描所有子目录，包括/proc、/sys这类不可读路径 - 它的
d键是rm -rf，选中一个软链接，按d删的是目标文件，不是链接本身 - 安全用法：
ncdu --exclude /proc --exclude /sys --exclude /dev /var/log，限定范围+排除虚拟文件系统
复杂点在于：没有“万能命令”。find 快但片面，du 准但慢，ncdu 直观但需预判范围——得根据你手头线索选：是告警说 /var 分区满？那就先 du -sh /var/* | sort -hr；是怀疑某个日志疯长？直接 find /var/log -name "*.log" -size +500M。
