Linux 磁盘满了别急着删文件：用 df 和 du 四步定位真凶

服务器突然告警磁盘使用率 100%，网站打不开、数据库写不进、连登录都可能变慢。很多人第一反应是凭感觉删几个大文件，结果删错日志、删掉正在写的文件，问题反而更糟。磁盘满了要先定位：到底是哪类东西占了空间，再决定能不能删、怎么删。

第一步：先看整体，确认是哪块盘满了

用 df -h 看各挂载点的使用率。重点看 / 和 /var、/data 这些常用挂载点。如果根分区满了，再看是不是某个挂载点没挂上，导致数据写到了根分区下面——这种情况删文件没用，得先把盘挂好。

还有一个容易被忽略的可能：inode 用完了。用 df -i 看 inode 使用率，如果 inode 到了 100%，即使磁盘还有空间也写不进新文件。大量小文件（比如缓存、会话文件、邮件队列）最容易把 inode 耗尽，这时要清的是文件数量，而不是文件体积。

第二步：用 du 一层层往下找

确认了满的分区后，用 du -sh /* 看根目录下每个目录的大小，再对最大的那个继续往下钻，比如 du -sh /var/*。这样一层层缩小范围，几分钟就能定位到具体目录。嫌手动麻烦也可以用 du -h --max-depth=2 /var | sort -rh | head -20，直接列出最大的前 20 个。

新手常踩的坑是直接对整个根分区跑 du -sh /，又慢又没用；分层钻取才是正确姿势。还要注意 du 默认不跨文件系统，如果怀疑某个挂载点有问题，加 -x 限制在同一个文件系统内，避免把其他盘的数据也算进来。

第三步：认清三类常见“真凶”，删法各不相同

第一类是日志文件。/var/log 下的日志、Nginx 或应用的访问日志最容易失控。先用 ls -lh /var/log 看大小，再用 tail 确认日志还在正常滚动。删除正在被进程写着的日志文件要小心：直接 rm 删掉后，文件句柄还在进程手里，空间并不会释放，必须重启对应服务或者用 : > file.log 把文件截断为空，后者不用重启服务，空间立刻释放。长远看要配好 logrotate，让日志自动轮转压缩。

第二类是 Docker 相关。docker system df 能看到镜像、容器、构建缓存各占多少。很多机器磁盘满就是构建缓存和悬空镜像堆出来的。docker system prune -a 可以清理未使用的镜像和缓存，但执行前先确认没有正在用的镜像会被误删，生产机上最好先 docker images 看一眼。

第三类是应用缓存和临时文件。/tmp 下的旧文件、应用的上传临时目录、数据库的慢查询日志都可能悄悄膨胀。这类文件删之前先确认没有进程正在用，lsof +L1 可以列出已被删除但仍被进程占用的文件——这些文件表面上已经不在目录里了，空间却一直没释放，重启对应进程才能真正腾出空间。

第四步：删完验证，再做预防

清理后重新跑 df -h，确认使用率降下来了。如果删了不少文件使用率却纹丝不动，多半是上面说的“已删除仍被占用”的情况，用 lsof | grep deleted 找出来，重启对应进程。

更重要的是预防而不是救火。给关键目录设个简单的监控：写个 cron 任务每天跑 df -h，使用率超过 80% 就发告警；日志配好 logrotate 的轮转周期和保留份数；Docker 机器定期跑 docker system prune。磁盘满从来不是突然发生的，都是慢慢涨上来的——早发现，早处理，就不用在半夜删文件救火。

最后提醒一句：删文件之前先问一句“这个文件删了会不会影响正在跑的服务”，不确定的先移走而不是删除，观察一天没问题再删。磁盘空间可以慢慢腾，删错数据的代价却很难挽回。