df与du差值不是误差而是关键线索，95GB与60GB的差值大概率是已rm但进程未释放句柄的“幽灵文件”，需用sudo lsof +L1定位并优雅重启对应服务释放空间。
磁盘空间告警时，df 和 du 的差值不是误差，而是关键线索。真正的问题往往藏在“df 看得见、du 找不到”的地方。
先用 df 锁定问题分区和异常类型
执行 df -h 查所有挂载点，重点关注 Use% ≥ 90% 的分区（如 /、/var、/home）。确认目标后，立刻运行 df -i 检查 inode 使用率：
- 若 IUse% ≥ 95%，说明小文件密集（如日志轮转未清理、容器临时文件、邮件队列），删大文件无效，应清理或轮转对应目录（如 /var/log/journal、/var/spool/mail）
- 若 Use% 高但 IUse% 很低（比如 98% vs 12%），说明是大文件或已删未释放文件在占块空间，进入下一步排查
- 注意 ext4 默认为 root 保留 5% 空间，这部分计入 Used 但不显示在 du 中，属正常现象
再用 du 分层定位可见大户
进入高占用分区根目录（如 cd /var），运行：
- du -sh --max-depth=1 2>/dev/null | sort -hr：列出一级子目录总大小，快速识别前几名（如 /var/log、/var/cache）
- 对排前三的目录继续下钻，例如：du -sh log/* 2>/dev/null | sort -hr | head -5
- 加 --exclude=/proc --exclude=/sys --exclude=/dev 避免虚拟文件系统干扰统计
用 find 快速抓出孤立大文件
当目录内文件极多、du 扫描慢时，直接按 size 筛选更高效：
- find /var -type f -size +500M -exec ls -lh {} \; 2>/dev/null
- 限定范围提速：find /var/log -name "*.log" -size +100M -exec ls -lh {} \;
- 对匹配到的大文件，用 lsof -nP | grep "filename" 确认是否被进程持续写入（如 catalina.out、nginx.log）
最后用 lsof 揪出已删未释放的“幽灵文件”
如果 df 显示用了 95GB，du 加起来才 60GB，差值大概率是已 rm 但进程未关闭句柄的文件：
- 运行 sudo lsof +L1（需 root 权限），列出所有链接数为 0 的打开文件
- 输出中类似这行就是线索：java 1234 root 1w REG 8,1 2.1G 123456 /var/log/app.log (deleted)
- 对应该 PID 的服务，优先使用 systemctl restart xxx 或优雅 reload 释放空间，避免 kill -9
