本文将从实际运维场景出发，分步骤讲解如何科学诊断磁盘使用情况、精准定位占用源、安全释放空间，并在必要时实施扩容操作。同时，我们还将介绍如何通过自动化监控和定期维护机制，从根本上预防此类问题反复发生。无论你是刚入行的初级运维，还是经验丰富的系统架构师，都能从中获得实用价值。
首先，明确一点：磁盘空间不足并不总是因为“文件太多”。在Linux系统中，即使你删除了一个被进程打开的文件，只要该进程未重启，磁盘空间仍不会被释放。这是许多新手容易踩的“隐形坑”。因此，第一步不是急着删东西，而是准确诊断——到底是谁占用了空间？
要实现精准诊断，推荐使用几个核心命令组合。首先是df -h，它能快速显示各挂载点的使用率。如果发现根分区（/）使用率超过90%，就需要进一步排查。接着使用du -shx /* 2>/dev/null | sort -hr | head -10，这条命令会列出根目录下占用最大的10个目录（-x参数确保不跨文件系统，避免统计挂载点下的其他磁盘）。通过这种方式，你可以快速锁定问题区域，比如/var、/home或/opt等。
特别值得注意的是/var目录，它通常是日志、缓存和临时文件的集中地。以/var/log为例，某些应用（如Nginx、MySQL、Docker）若未配置日志轮转，可能在数天内生成数十GB的日志文件。此时，不要直接rm -f *.log，而应先检查是否有进程正在写入。使用lsof +L1命令可以列出所有已删除但仍被进程占用的文件（即“deleted”状态的文件），这些文件虽然看不见，却仍在消耗磁盘空间。解决方法是重启对应服务，或发送USR1信号触发日志切割（如kill -USR1 $(cat /var/run/nginx.pid)）。
除了日志，缓存文件也是常见“空间吞噬者”。例如，Docker镜像、容器日志、YUM缓存、npm缓存等都可能在不知不觉中积累大量数据。对于Docker用户，docker system df可查看镜像、容器、卷的占用情况；执行docker system prune -a -f可安全清理未使用的资源（注意：-a会删除所有未被容器引用的镜图，需谨慎）。对于系统级缓存，yum clean all（CentOS/RHEL）或apt clean（Ubuntu/Debian）能有效释放空间。
另一个容易被忽视的是临时文件。/tmp和/var/tmp目录中的文件理论上应由系统自动清理，但某些应用可能长期驻留临时数据。使用find /tmp -type f -atime +7 -delete可删除7天未访问的临时文件（请先测试find命令是否返回预期结果再加-delete）。此外，检查是否有用户在/home下存放大量非业务数据，这也是常见隐患。
在清理过程中，务必遵循“先备份、再操作”原则。对于不确定是否可删除的文件，建议先mv到备份目录，观察系统运行24小时后再决定是否彻底删除。同时，避免在业务高峰期执行大规模清理操作，以免I/O压力影响服务性能。
如果经过全面清理后空间仍紧张，或业务增长确实需要更多存储，那么扩容就是不可避免的选择。扩容方式主要有两种：一是扩展现有磁盘（适用于云服务器），二是挂载新磁盘（适用于物理机或虚拟机）。
以AWS EC2为例，你可以先在控制台将EBS卷容量从100GB扩展到200GB，然后在实例内执行以下步骤：使用lsblk确认新容量已识别；使用growpart /dev/xvda 1扩展分区（假设是第一个分区）；最后用resize2fs /dev/xvda1（ext4）或xfs_growfs /（xfs）扩展文件系统。整个过程无需重启，但建议在维护窗口期操作。
对于物理服务器，若无法扩展原盘，可添加新硬盘并挂载到特定目录。例如，将新磁盘/dev/sdb格式化为ext4后，挂载到/data，并将应用的数据目录（如MySQL的datadir）迁移到该位置。迁移前需停止相关服务，使用rsync -avP /var/lib/mysql/ /data/mysql/确保数据一致性，再修改配置文件指向新路径。此方法不仅能解决空间问题，还能实现I/O负载分离，提升性能。
当然，扩容并非万能。如果频繁遭遇空间不足，说明缺乏有效的容量规划。建议建立磁盘使用趋势监控机制。利用Prometheus + Node Exporter + Grafana组合，可实时采集各分区使用率，并设置阈值告警（如>85%时触发企业微信/钉钉通知）。同时，结合日志管理工具（如ELK或Loki），将日志集中收集并设置保留策略，避免本地堆积。
此外，制定定期维护计划也至关重要。例如，每周日凌晨2点执行一次自动化脚本，清理过期日志、缓存和临时文件。脚本可包含以下逻辑：1）检查各分区使用率；2）若超过80%，则执行预设清理规则；3）记录操作日志并发送摘要邮件。这样既能防患于未然，又能减少人工干预成本。
最后，提醒一点：不要过度依赖“清理”来解决问题。良好的架构设计才是根本。例如，将静态资源托管到对象存储（如S3、OSS），数据库启用自动归档，应用日志采用异步写入远程日志服务器等，都能显著降低本地磁盘压力。在系统设计初期就考虑存储生命周期管理，远比事后救火更高效、更安全。
总结来说，应对服务器磁盘空间不足，不能只靠“删文件”这一招。正确的做法是：先诊断，再清理，必要时扩容，最后通过监控与自动化实现长效治理。只有形成闭环管理，才能真正告别“磁盘告急”的焦虑，让系统运行更稳定、更高效。希望本文提供的系统性方案，能为你在实际运维中提供可靠参考。