上周三凌晨两点，磁盘手机监控告警把我吵醒：一台跑了三年 Laravel 项目的不够服务器，磁盘使用率 98%。用清SSH 上去 df -h 一看，磁盘40G 的不够盘只剩 800M。这不是用清第一次了，但那次特别急——队列任务开始报错，磁盘日志写不进去，不够整个应用半死不活。用清

如果你也遇到这种情况，磁盘先别急着删东西。不够搞清楚空间被谁吃了，用清比乱删一通重要得多。磁盘

先定位，不够别瞎猜

df -h 看整体，用清du -sh /* 从根目录一层层往下查。我那次发现 /var/log 占了 18G，/storage 占了 12G。Laravel 的日志默认写在 storage/logs/laravel.log，如果不配置轮转，这个文件能长到几个 G。另外 storage/framework/cache、storage/framework/sessions、storage/framework/views 这三个目录也容易堆积。

还有个小坑：du 和 df 结果对不上，通常是文件被删了但进程还占着句柄。用 lsof | grep deleted 查一下，重启对应进程就能释放。

日志是头号嫌疑犯

Laravel 默认的 single 日志驱动就是个定时炸弹。改成 daily，在 config/app.php 里设 'log' => 'daily'，再配个 log_max_files，比如 14 天。已经生成的巨型日志文件，直接 truncate -s 0 laravel.log 比 rm 更安全——进程还在写的话，rm 不会真正释放空间。

Nginx 和 PHP-FPM 的日志也别放过。/var/log/nginx/access.log 在高流量站点能一天涨几百 M。用 logrotate 配置轮转，或者干脆在 Nginx 里关掉 access_log（如果不需要分析的话）。

缓存和 session 文件

php artisan cache:clear 和 php artisan view:clear 是基本操作。但文件缓存和 session 如果存在磁盘上，storage/framework/cache/data 和 storage/framework/sessions 会积累大量小文件。php artisan cache:clear 不一定能清干净文件缓存，手动删 storage/framework/cache/data/* 更彻底。

我习惯在 Kernel.php 的 schedule 里加一条：每周跑一次 cache:clear 和 view:clear。session 文件设个过期时间，Laravel 的 session.lifetime 默认 120 分钟，但过期的文件不会自动删。加个定时任务清理 storage/framework/sessions 下超过两天的文件。

队列失败任务和旧备份

failed_jobs 表如果不用数据库队列，失败任务会以文件形式存在 storage/framework/queue 里？不，Laravel 的失败任务默认写数据库。但如果你用 sync 驱动或者自定义了失败处理，检查一下 storage/logs 里有没有 queue 相关的日志。

旧备份是另一个隐形杀手。我见过有人把数据库备份直接扔在 /home 下，半年攒了 30G。备份要么传到 S3，要么设个保留策略，比如只留最近 7 天。

大文件排查和紧急处理

find / -type f -size +100M -exec ls -lh { } \; 这条命令能揪出所有超过 100M 的文件。我上次跑完发现一个 4G 的 core dump 文件躺在 /tmp 里，是某个 PHP 进程崩溃留下的。删掉就行。

紧急情况下，echo > laravel.log 比 rm 快，而且不影响正在写的进程。清完空间后，记得 df -h 确认一下，有时候删了文件但空间没释放，就是句柄没关。

预防比救火重要

装个 logrotate，配好 Laravel 日志的轮转规则。监控磁盘使用率，80% 就告警。别等 98% 再动手，那时候应用已经在报错了。队列驱动用 Redis 而不是数据库，能省不少磁盘 I/O 和空间。定期跑 php artisan model:prune 清理软删除的旧记录，如果模型配了 Prunable 的话。

那台服务器后来我加了 20G 盘，但更重要的是把日志驱动改了，加了定时清理任务。三个月过去，磁盘再没超过 60%。