当Linux服务器提示磁盘空间不足时，系统可能出现无法写入日志、服务崩溃或无法安装更新等问题。要彻底解决这一状况，需要按照从定位到清理再到预防的顺序进行处理，而不是盲目删除文件。
一、快速定位磁盘占用情况
第一步应当使用df命令查看整体磁盘分区的使用情况。该命令可以显示出每个挂载点的总容量、已用空间和可用空间，帮助我们判断到底是哪一个分区出现了空间耗尽。通常根分区（/）或者日志所在分区（如/var）最容易出问题。
在确认了具体分区之后，需要借助du命令逐层查找占用空间较大的目录。例如从根目录开始，按大小排序找出前几个目录，再进入子目录继续分析。这种由粗到细的排查方式能避免在全盘扫描时浪费大量时间。
# 查看所有挂载点使用情况
df -h
# 查看根目录下各子目录占用空间，按人类可读方式显示
du -h --max-depth=1 / | sort -hr
# 找出当前目录下大于100M的文件
find / -type f -size +100M -exec ls -lh {} ;
二、常见空间占用来源与清理手段
日志文件是Linux系统中最容易被忽视的空间消耗者。许多服务会将运行日志记录在/var/log目录中，如果未配置日志轮转，单个文件可能增长到数吉字节。使用logrotate工具或手动清空旧日志，可以立即释放空间，但应注意不要直接删除正在被进程占用的日志文件，而应使用重定向清空。
软件包缓存同样会占用不少空间。在基于Debian的系统中，apt下载的deb包会保留在/var/cache/apt/archives；在Red Hat系中，yum或dnf也有类似缓存目录。执行清理命令可删除这些已安装完毕的临时包文件，且不会影响系统正常运行。
# 清空正在写入的日志而不删除文件本身 > /var/log/syslog # 清理apt缓存 apt-get clean # 清理yum/dnf缓存 dnf clean all
三、容器环境下的空间回收
若服务器运行了Docker，磁盘满的原因常常是悬空镜像、停止的容器以及未被清理的数据卷。Docker不会自动删除这些资源，长期累积会占满存储。通过docker system df可以查看各类资源占用，再使用docker system prune进行安全回收。
需要注意的是，默认prune命令不会删除未被容器引用的数据卷，因为其中可能存有业务数据。如果确认某些卷已无用，应显式添加参数清理，或在删除容器时一并移除卷。此外，定期设置镜像拉取上限和日志驱动大小限制，能从源头控制容器对磁盘的消耗。
# 查看docker磁盘使用 docker system df # 清理停止的容器、悬空网络、悬空镜像 docker system prune # 同时清理未被使用的数据卷（谨慎） docker system prune -a --volumes
四、建立长期预防机制
解决一次空间不足后，若不加以防范，问题仍会反复。建议对关键目录如/var/log、/tmp设置磁盘配额，或者利用systemd的临时文件清理规则自动移除旧文件。这样可以在空间达到阈值前就完成自动回收。
另一个有效手段是配置监控告警。通过Node Exporter配合Prometheus，或简单的cron脚本定时检查df输出，当可用空间低于百分之十时发送通知。管理员便能在服务受影响前介入处理，而不是等磁盘写满后才被动响应。
# 每天检查根分区剩余空间，低于10%时打印告警
#!/bin/bash
usage=$(df / | awk 'NR==2 {print $5}' | sed 's/%//')
if [ "$usage" -gt 90 ]; then
echo "根分区使用率超过90%，请及时清理"
fi
五、误删风险与恢复建议
清理过程中最忌讳盲目使用rm -rf删除不熟悉的目录。某些目录如/proc、/sys是虚拟文件系统，删除不仅无效还可能引发异常；而/lib、/usr下的文件误删会导致命令无法执行。因此删除前务必用du确认内容，并优先采用各软件自带的清理命令。
如果误删了重要文件但进程仍在使用该文件，可通过/proc/进程ID/fd目录尝试恢复句柄。不过这仅适用于文件被删除但未被释放的场景，平时仍应以备份和谨慎操作为主，避免将清理变成事故。
磁盘空间管理是Linux运维的基本功，定位准、清理稳、预防早，才能保障业务持续稳定运行。