应先用 df -h 定位 95%+ 满载挂载点（如 /var），再用 find /var -xdev -type f -size +500m 2>/dev/null 精准查找大文件；若 df -h 不降，需 lsof +l1 查已删未释放文件，并依类型用 truncate、journalctl 或 docker prune 清理。
先确认哪块盘真满了，别瞎扫
直接 find / -size +1G 是最常见也最危险的起点——它会卡在 /proc、/sys，还可能误扫 NFS 或容器卷，甚至触发 OOM Killer。真正该做的，是先看 df -h 输出里哪个挂载点用了 95%+，比如 /dev/sda1 挂在 /var，那就只查 /var，不碰根目录其他部分。
关键控制点：
-
df -h /var确认路径归属分区，避免删错挂载点 - 加
-xdev（或-mount）：find /var -xdev -type f -size +500M，防跨文件系统 - 屏蔽权限错误：末尾加
2>/dev/null，不然Permission denied刷屏盖住真实结果
找到文件后，先查它是不是正被进程攥着
删完 df -h 不变？八成是文件已被 rm，但某个进程还在往它的 inode 写数据——目录项没了，数据块和句柄还在。这时候 lsof /path/to/file 能看到 WRITE 句柄；更直接的是 lsof +L1，它专列“已删但未释放”的文件，输出像这样：
rsyslogd 1234 root 1w REG 253,1 1287454720 0 123456 /var/log/syslog (deleted)
别急着 kill -9：
- 日志类服务（
rsyslogd、journalctl）优先发kill -HUP 1234，让它重开文件 - 实在要清空，用
truncate -s 0 /var/log/syslog，比rm安全——inode 不变，写入不中断 -
echo "" > /var/log/syslog看似等效，但 shell 权限不足时会失败；truncate更可靠
按场景选清理方式，不是所有大文件都该 rm -f
同一个 /var/log/app.log，处理方式完全不同：
- 确认无进程打开、非数据库 WAL/binlog、非包管理器缓存（如
/var/cache/apt/archives/）→ 可rm -f - 是滚动日志且还在写入 → 用
truncate -s 0，不删文件只清内容 - 属于 systemd journal → 用
journalctl --vacuum-size=300M，别硬删/var/log/journal - 是 Docker overlay2 层 → 别直接删
/var/lib/docker/overlay2/xxx，用docker system prune -a或docker image prune
特别注意：du -sh /* 和 df -h 对不上时，差值大概率就是 lsof +L1 里那些 “(deleted)” 文件占着的空间。
删之前必须手动核对三件事
运维事故里，80% 的“删完服务崩了”，源于没花 30 秒验证：
- 运行
lsof /path/to/file，确认没有WRITE或DEL状态句柄 - 执行
df /path/to/file，确保目标路径确实在你要清理的满载分区上 - 查文件类型：
file /path/to/file看是不是二进制 core dump、数据库日志（如mysql-bin.000001）、或加密备份——这些不能随便清
最后提醒一句：df -i 得同步看。小文件太多（比如千万级 session 文件）会导致 inodes 耗尽，此时 df -h 显示空间充足，却报 “No space left on device”。这种情况下，再大的 find -size 都救不了你。
