磁盘空间不足时应先用df -h定位高占用分区，再用du -sh * | sort -hr | head -10查找大目录，接着用lsof检查被删除但未释放空间的文件，最后针对性清理日志、缓存等。
磁盘空间不足时，先别急着删文件。关键是要快速定位“谁占了最多空间”，避免误删系统文件或正在被进程占用的日志。核心就两步：用 df 锁定问题分区，再用 du 钻进目录找大目标。
第一步：用 df -h 快速定位哪个分区满了
执行命令：
df -h
看 Use% 列，重点关注超过 90% 的挂载点（比如 /、/var、/home）。注意两点：
- 只看已挂载的物理分区，像 tmpfs、devtmpfs 这类内存文件系统不用管
- 如果发现根目录 / 使用率高，但不确定是哪个子目录导致的，继续往下查
第二步：用 du 找出大目录和大文件
进入高占用分区的挂载点（如 cd /），运行：
du -sh * 2>/dev/null | sort -hr | head -10
这条命令会列出当前目录下前 10 个最大的子目录（单位自动适配，按大小倒序）。常见大户有：
- /var/log：系统和服务日志，尤其 tomcat、nginx、journalctl 日志容易暴涨
- /var/cache：包管理器缓存（如 yum/apt）长期不清理会占几个 GB
- /home 或 /root：用户下载、临时解压包、core dump 文件
找到可疑目录后，可进一步深入，比如：
du -sh /var/log/* 2>/dev/null | sort -hr | head -5
第三步：检查被删除但未释放的空间
有时删了大文件，df 显示空间没回来——大概率是文件被进程持续打开并写入（如日志轮转后旧文件被删，但服务还在往它写）。查这类“幽灵占用”：
lsof +L1 或 lsof | grep deleted
输出中会看到类似这样的行：
java 1234 root 1w REG 8,1 2.1G 123456 /var/log/app.log (deleted)
说明 PID 1234 的进程正往一个已被删除的文件写入。解决办法只有两个：
- 重启对应服务（推荐，安全）
- 或 kill -HUP 该进程（部分服务支持重载，不中断写入）
第四步：辅助排查与清理建议
日常维护可配合这些技巧：
- 找超大单文件：find / -type f -size +500M 2>/dev/null | xargs ls -lh
- 交互式分析（需安装）：ncdu / —— 方向键浏览，D 键直接删除，比 du 更直观
- 清空 journal 日志：journalctl --disk-usage → journalctl --vacuum-size=200M
- 清理 yum 缓存：yum clean all（CentOS/RHEL）或 apt autoremove && apt clean（Ubuntu/Debian）
基本上就这些。流程不复杂但容易忽略细节，比如跳过 lsof 检查直接删日志，结果空间不释放还可能引发服务异常。
