<p>最有效的起点是运行 du -sh /* 2>/dev/null，可快速识别根目录下占用最大的一级子目录（如 /var、/usr、/home），其中 2>/dev/null 屏蔽权限错误，-s 汇总、-h 人性化显示。</p>
du -sh /* 2>/dev/null 是最有效的起点
直接在 root 目录下运行 du -sh /* 2>/dev/null，能快速筛出占用空间最大的一级子目录（如 /var、/usr、/home）。2>/dev/null 必须加，否则大量权限拒绝错误会冲掉有效结果；-s 表示汇总，-h 让数值可读。别从 du -sh . 开始——当前目录可能只是冰山一角，根目录才是全局视角。
进入大目录后用 du -sh * | sort -hr 定位“真凶”子目录
比如发现 /var 占用异常高，就 cd /var 然后执行 du -sh * 2>/dev/null | sort -hr | head -20。注意三点：
-
sort -hr按人类可读大小逆序排（G > M > K），比单纯sort -n可靠得多 - 常见高危目录：
/var/log（未轮转日志）、/var/lib/docker（容器镜像/层）、/var/cache（yum/apt 缓存） - 如果某目录显示大小为 0 或极小但实际应很大，说明可能被挂载覆盖了（比如
/var/lib/mysql下挂了新分区），需mount | grep var检查
find + du 组合查大文件，避开 du 的递归开销
当 du 跑得太慢或结果不一致（比如 df -h 显示用了 95%，但所有 du 加起来只有 70%），说明有“已删除但进程仍在写”的文件。这时别硬啃 du，改用：
-
find /var -type f -size +100M -exec du -sh {} \; 2>/dev/null—— 在指定路径下找大文件，比全盘du快得多 -
lsof +L1或lsof | grep deleted—— 直接列出已被删除但仍被进程打开的文件，这才是df和du不一致的主因 - 查到 PID 后，别急着
kill -9，先ps -p PID -o comm=看进程名，优先用服务管理命令重启（如systemctl restart rsyslog）
注意 ext4 的 5% 保留空间和 inode 耗尽两种“假满”
df -h 显示 100%，但 du 总和远小于它，除了被删未释放的文件，还有两个隐蔽原因：
- ext4 默认为 root 预留 5% 空间（
tune2fs -l /dev/vda1 | grep "Reserved block count"可确认），普通用户看不到这部分，但df会计入。紧急时可用tune2fs -m 1 /dev/vda1降到 1% -
df -i查 inode 使用率，IUse%到 100% 也会报No space left on device，尤其在大量小文件场景（如 Web 缓存、邮件队列）。此时find /path -xdev -type f | wc -l可粗略统计文件数
真正难排查的从来不是“哪个目录大”，而是“为什么 du 算不准”——那多半是进程在后台偷偷占着已删文件，或者 inode 已死。盯着 df -h 和 df -i 的差值，比盲目删日志更管用。
