先用 df - h 定位高占用分区，再用 du -sh /* 逐层下钻查大目录，接着用 find -size +500M 揪大文件，最后用 lsof +L1 排查已删仍被占用的“僵尸”文件。
磁盘空间告警一响，别急着删文件。先精准定位“吃空间”的源头，再安全清理，才是稳准快的关键。
看全局：用 df 快速锁定问题分区
执行 df -h，重点盯 Use% 列——超过 95% 就要处理。注意挂载点（Mounted on），比如/、/var 或/data。若多个分区都高负载，优先处理 Use% 为 100% 或接近的那一个。
查大目录：du 命令分层下钻，不盲目扫全盘
对问题分区根目录执行：
sudo du -sh /* 2>/dev/NULL | sort -hr
这能快速列出顶层子目录大小。常见“大户”有：
– /var/log（日志 堆积）
– /var/lib/docker（docker镜像 / 容器 / 日志）
– /tmp（残留临时文件）
– /home或/data（业务数据或上传文件）
找到最大目录后，cd 进去，重复执行du -sh * | sort -hr，逐层缩小范围。
揪大文件：find 比 du 更直接，尤其适合定位单个“巨无霸”
当怀疑是少数几个超大文件占满空间时，用 find 更高效：
find / -xdev -type f -size +500M 2>/dev/null -exec du -h {} ; | sort -hr | head -n 20
说明：
– -xdev避免跨分区搜索（防止误入其他挂载点）
– +500M可按需调整，如 +1G、+100M
– 常见目标：*-json.log（Docker 容器日志）、.log、.tar.gz、core文件
别漏掉隐藏“僵尸”：已删但进程仍在占用的文件
有时 df 显示已满，du却算不出对应大目录——很可能是文件被 rm 了，但进程还在写它。运行：
lsof +L1 或 lsof | grep deleted
输出中会显示 PID 和文件路径。解决方法：
– 重启对应服务（如systemctl restart nginx）
– 或直接 kill -HUP PID（若支持重载）
空间会立刻释放，无需重启整机。
基本上就这些。工具 不多，关键是顺序不能乱：df → du 分层 → find 精筛 → lsof 兜底。不复杂但容易忽略。
