相信很多后端开发者和运维同学都遇到过这样的惊险时刻：线上服务器突然报警，SSH 登录一看，磁盘空间占用率直逼 100%！系统越来越卡，甚至随时可能因为写不进文件而导致数据库崩溃、Web 服务宕机。
最近，我的服务器就遭遇了这一幕，170多G的硬盘被吃得干干净净。经过一步步排查，我最终安全释放了将近 70G 的空间，并且找到了导致硬盘撑爆的“真凶”。
今天，就把这次排查与清理的完整过程复盘出来，教大家如何像老中医一样“望闻问切”，安全、优雅地给 Linux 服务器瘦身。
第一步：顺藤摸瓜，找出系统“大胃王”
面对爆满的磁盘，第一步千万别慌，我们需要知道空间到底被谁吃了。在 Linux 下，最强大的空间排查工具就是 du 命令。
为了从宏观上俯瞰整个文件系统，我直接在根目录下执行了以下命令：
sudo du -h --max-depth=1 / 2>/dev/null | sort -hr
命令原理解析：
du -h：以人类可读的方式（如 K、M、G）显示文件大小。--max-depth=1：只看当前层级（也就是一级目录），防止输出无限向下延展，让人眼花缭乱。2>/dev/null：这是一个运维小贴士。过滤掉那些由于系统进程变动产生的烦人报错（如/proc目录的权限提示），让输出界面保持清爽。sort -hr：按数字大小倒序排列（从大到小）。
命令跑完后，结果一目了然：
173G /
156G /www
9.6G /.Recycle_bin
3.7G /usr
...
破案的第一条线索出现了：总共 173G 的空间，有 156G 全都在 /www 目录下。熟悉宝塔面板（BT Panel）的同学肯定知道，这里存放着我们所有的网站源码、数据库和各类运行日志。
第二步：深入虎穴，逐层剥茧
既然知道了大头在 /www，我们继续用同样的方法向下钻取：
sudo du -h --max-depth=1 /www 2>/dev/null | sort -hr
输出结果如下：
156G /www
71G /www/wwwroot
38G /www/backup
23G /www/wwwlogs
19G /www/ytxy-xiyi-koa2-online
...
情况越来越清晰了。服务器的存储主要消耗在四个地方：
- wwwroot (71G)：网站根目录。
- backup (38G)：系统的历史自动备份文件。
- wwwlogs (23G)：Nginx/Apache 的访问日志。
- 一个孤立的 Koa2 项目 (19G)：这引起了我的注意，一个单纯的 Node.js 后端项目，怎么可能有 19G 这么大？
我决定继续排查最大的 wwwroot 目录，看看那 71G 到底装了什么。
sudo du -h --max-depth=1 /www/wwwroot 2>/dev/null | sort -hr
惊掉下巴的事情出现了：
39G /www/wwwroot/ytxy-xiyi-koa2-online
5.3G /www/wwwroot/wash-machine-service
...
在 wwwroot 内部，竟然还有一个同名的 Koa2 项目，并且占用了高达 39G 的空间！
这意味着，这一个 Node.js 项目的代码（可能包含了外层废弃的旧版本和当前运行的新版本），在我的服务器上硬生生吃掉了接近 60G 的硬盘。
第三步：揪出真凶，竟然是 Node.js 日志爆炸
纯代码项目哪怕加上 node_modules，撑死也就几百兆。几十个G的体积只有一种可能——日志。
我直接进入了这个 39G 的项目目录看个究竟：
sudo du -h --max-depth=1 /www/wwwroot/ytxy-xiyi-koa2-online 2>/dev/null | sort -hr
果然，39G 空间 100% 被项目里的 logs 目录霸占了。
这是很多 Node.js 新手（尤其是用 PM2 部署线上服务时）经常踩的坑：程序每天都在疯狂输出运行日志、请求日志和报错日志，但没有配置自动分割和清理。 日月累积，直到把服务器硬盘彻底撑爆。
第四步：千万别用 rm！优雅且安全的清理大法
找到了 39G 的垃圾日志，很多人可能第一反应就是敲下 rm -rf。千万别这么做！
为什么？因为你的 Node.js 线上项目还在跑着！如果直接用 rm 删除了日志文件，操作系统的文件系统虽然把文件名抹掉了，但是 Node 进程依然死死“握”着这个文件的句柄（File Descriptor）。
结果就是：文件看起来没了，但磁盘空间根本没有释放，甚至进程还会因为找不到文件而报错崩溃。
运维老鸟的正确做法是：清空文件内容，而不删除文件本身。
我使用了这行一行流命令：
sudo find /www/wwwroot/ytxy-xiyi-koa2-online/logs -type f -exec bash -c '> "$1"' _ {} \;
原理解析：
它会找出 logs 目录下的所有文件，并通过 > "$1" 将每一个文件瞬间“截断”为 0 字节。这样，既瞬间释放了硬盘空间，又保证了原本的文件依然存在，正在运行的代码还能继续向里面愉快地写日志，业务 0 中断。
用同样的命令，我顺手把外层那个 19G 的废弃项目日志也给清空了。至此，成功拿回了将近 60G 的空间。
第五步：治本之策，配置日志自动轮转
空间是腾出来了，但如果不解决根源问题，几个月后这颗定时炸弹还会爆炸。
既然项目是用 PM2 守护进程运行的，最简单的治本方案就是安装 PM2 的官方日志管理插件 pm2-logrotate。
在终端执行：
pm2 install pm2-logrotate
安装完成后，插件会在后台静默运行。它默认会在每天的午夜，自动把日志切割成新的文件，并且自动删除老旧的日志，永远保持服务器磁盘的健康。这一切都不需要重启现有的业务进程，堪称完美。
第六步：顺手牵羊，干掉宝塔的隐藏垃圾
既然已经开搞了，我索性把服务器里其他几块“脂肪”也清理了一下。
1. 清理宝塔回收站 (9.6G)
很多时候在面板里删除了大文件，其实它们被移到了回收站。通过命令彻底粉碎：
sudo rm -rf /.Recycle_bin/*
2. 清理 Nginx 历史访问日志 (23G)/www/wwwlogs 里存放着经年累月的网站访客日志。如果不做安全审计和流量分析，留着毫无意义，同样用“截断大法”清空：
sudo find /www/wwwlogs -name "*.log" -type f -exec bash -c '> "$1"' _ {} \;
总结与复盘
经过这通操作，我总共为服务器抢救回了近 100G 的空间，警报彻底解除。
复盘这次经历，给大家留下三个避坑建议：
- 排查空间有章法：熟练掌握
du -h --max-depth=1 目录路径 | sort -hr，这能让你在任何复杂的服务器环境里迅速定位到“占用大户”。 - 清理日志忌用 rm：永远记住，对于正在运行的服务产生的日志，用
>截断清空（如echo "" > file.log），永远比rm更加安全可靠。 - 线上服务必配日志轮转：无论是用
pm2-logrotate，还是 Linux 自带的logrotate，或者在代码里配置log4js的存活周期，千万不要让程序无限制地写日志。
希望这篇实战记录能帮到遇到同样问题的你。你的服务器，现在还剩多少空间呢？赶快去查一查吧！
版权属于：soarli
本文链接：https://blog.soarli.top/archives/1131.html
转载时须注明出处及本声明。
