Laravel日志按天分割需设LOG_CHANNEL=daily并确保storage/logs可写，daily驱动自动创建带日期后缀的文件（如laravel-2026-06-25.log），默认保留5天，可通过'days'=>30调整；原生不支持按大小切分，须依赖logrotate实现size触发轮转。
直接改 LOG_CHANNEL 为 daily 最省事
5.5 默认用的是 single 通道，所有日志全塞进 storage/logs/laravel.log 一个文件里，不清理就滚雪球。改成 daily 后，Laravel 自动按天建新文件（如 laravel-2026-06-25.log），旧文件默认只保留 5 天。
操作只需两步：
- 修改
.env：把LOG_CHANNEL=single改成LOG_CHANNEL=daily - 加一行配置（可选但推荐）：在
config/app.php里加'log_max_files' => 30，把保留天数从 5 天提到 30 天
注意：daily 不支持按大小切分，它只认日期。如果你真需要“超 2MB 就切”，这个原生方案做不到。
logrotate 是更灵活的落地解法
Linux 系统自带的 logrotate 能真正按大小、时间、压缩、保留份数来控制，而且不依赖 Laravel 运行时，稳定可靠。对 storage/logs/laravel.log 做轮转，必须确保 Laravel 进程有权限重开日志文件（否则轮转后写不进去）。
典型配置示例（存为 /etc/logrotate.d/laravel）：
/path/to/your/project/storage/logs/laravel.log {
size 2M
rotate 100
compress
delaycompress
missingok
notifempty
create 644 www-data www-data
sharedscripts
}
关键点：
-
size 2M表示文件一超过 2MB 就触发轮转 -
create 644 www-data www-data必须匹配你的 Web 服务器用户（Nginx/Apache）和组，否则新日志文件权限不对，Laravel 写失败 -
sharedscripts确保脚本只执行一次，避免重复操作 - 改完后手动测试：
sudo logrotate -f /etc/logrotate.d/laravel
别漏掉 log_level 这个源头开关
日志太大，往往不是轮转没做好，而是写了太多不该写的。5.5 默认 log_level 是 debug，HTTP 请求、SQL 查询、变量 dump 全打出来，几秒就能撑爆一个文件。
生产环境务必调低：
-
.env中设LOG_LEVEL=error或LOG_LEVEL=warning - 如果要用
info，检查是否开了不必要的调试中间件（比如Debugbar、clockwork的日志输出） - 自定义日志时，避免在循环里打
Log::info()—— 一条请求可能刷出几百行
改完记得清缓存：php artisan config:clear，否则 .env 变更不生效。
手动清理或截断要小心权限和进程占用
临时救急可以清空日志，但直接 rm storage/logs/laravel.log 或 echo "" > storage/logs/laravel.log 很危险：Laravel 进程还拿着旧文件句柄，继续往已删除的 inode 写，磁盘空间不会释放，df 看不到变化，但 lsof | grep deleted 能查到。
安全做法只有两个：
- 用
truncate -s 0 storage/logs/laravel.log（前提是文件没被其他进程锁死） - 先停服务（
supervisorctl stop all或关掉 PHP-FPM），再删/清空，再重启
线上千万别在没停服务的情况下 rm 日志文件 —— 这是运维事故高发动作。
按大小切分这事，Laravel 5.5 原生不支持，硬要实现就得靠 logrotate 或自己写守护进程。多数场景下，daily + log_level 调整 + logrotate 三板斧组合，已经覆盖 95% 的日志膨胀问题。真正容易被忽略的，其实是 Web 服务器用户权限和 logrotate 的 create 参数是否匹配。
