登录服务器后先用 df -h 查看各挂载点使用率，重点关注 Use% 超 98% 的分区（如 / 或 /var），再用 df -i 检查 inode 是否耗尽；接着用 du 和 find 分层定位大目录和大文件，注意隐藏文件；若删除后空间未释放，用 lsof +L1 查找被进程占用的已删文件；清理优先 truncate、压缩或 logrotate，避免直接 rm；长期需配置日志轮转和定期清理脚本。
先看哪块盘满了
登录服务器后第一件事不是乱翻文件，而是用 df -h 快速确认哪个挂载点使用率超标。重点关注 Use% 列，比如显示 98% 或 100% 的分区（常见是 / 或 /var）。如果看到 tmpfs 或 devtmpfs 占用高不用管——它们是内存虚拟文件系统，不占真实磁盘。
顺手加个 df -i，检查 inode 是否耗尽。有些场景磁盘空间还有余量，但因生成了海量小文件（如日志碎片、缓存临时文件），导致 IUse% 达到 100%，这时 touch 新文件或写日志会失败，但 df -h 看不出异常。
定位“真凶”目录和文件
找到问题分区后，进入该挂载点（比如 cd /），用以下命令分层缩小范围：
-
查一级子目录总大小：
du -sh * 2>/dev/null | sort -hr | head -20—— 快速看出谁最吃空间，比如/var占 35G，/home占 2G -
进大目录继续深挖：
cd /var && du -sh * 2>/dev/null | sort -hr | head -10—— 很可能发现/var/log或/var/lib/docker是元凶 -
找具体大文件：
find /var/log -type f -size +100M -exec ls -lh {} \;—— 直接列出所有超 100MB 的日志文件 -
别漏隐藏文件：
du -ah --max-depth=1 . | sort -rh | head -15——-a包含点开头的隐藏项，有时.cache或.local/share暗藏巨无霸
注意“删了也白删”的陷阱
执行 rm 后 df -h 空间没释放？大概率是文件已被删除，但仍有进程在读写它，系统无法真正回收空间。
用这两个命令验证：
-
lsof +L1—— 列出所有已删除但仍被打开的文件（带DEL标记） -
lsof | grep deleted—— 更直观，附带 PID 和进程名
例如输出里有 java 1234 root 12w REG 8,1 2.1G ... /var/log/app.log (deleted)，说明 Java 进程还在往这个已删文件写日志。解决办法是：重启对应服务（推荐），或 kill -HUP 1234（若支持重载日志句柄），不建议直接 kill -9 除非确认无影响。
安全清理与长期预防
确认目标后，清理要讲策略：
- 日志类：优先用
truncate -s 0 /path/to/big.log清空内容（保留文件句柄，不中断服务），或gzip压缩后删原文件 - 临时目录：
find /tmp -mtime +7 -delete、find /var/tmp -mtime +7 -delete - 包管理缓存：
apt-get clean（Debian/Ubuntu）或yum clean all（RHEL/CentOS） - 旧内核：
dpkg --list | grep '^ii linux-image-' | awk '{print $2}' | sort -V | sed -n '/'$(uname -r)'!p' | xargs apt-get -y purge（Ubuntu）
长期预防靠两件事：一是配好 logrotate（比如 /etc/logrotate.d/nginx），二是定期跑轻量清理脚本（每天清 7 天前日志 + 压缩超 500MB 的活跃日志）。不需要全自动删一切，留 10%~15% 缓冲空间更稳妥。
基本上就这些。流程不复杂，但容易忽略 inode、deleted 文件、隐藏路径这三处关键盲点。
