安全，但需避开正在被写入的文件；Laravel默认按天轮转日志，当前laravel.log不可删，归档文件如laravel-2024-06-15.log可放心删除。
直接删除 storage/logs 目录下的日志文件是否安全
安全，但需避开正在被写入的文件。Laravel 默认使用 RotatingFileHandler（通过 Monolog），日志按天轮转，当前日志是 laravel.log，其余如 laravel-2024-06-15.log 是归档文件，可放心删。注意：不要手动删 laravel.log 同时又让 PHP 进程持续写入——可能触发 file_put_contents(): failed to open stream: No such file or directory 错误，因为 Laravel 持有该文件句柄。
用 php artisan log:clear 清理的前提和限制
Laravel 9.2+ 内置了这个命令，但它只清理 storage/logs 下后缀为 .log 的文件，且默认不删 laravel.log（除非加 --force）。执行前需确认：
-
APP_ENV是local或staging；生产环境默认禁用该命令（防止误操作） - 确保
storage/logs目录可写，否则报错Permission denied - 若自定义了日志通道（比如改用
daily并设了days => 30），log:clear不会自动清理过期归档，它只是“暴力删所有 .log”
用 shell 脚本定期清理更可控
比 Artisan 命令更适合生产环境，能精准保留最近 N 天日志、跳过正在写的文件、避免权限中断。例如在服务器上加个 cron：
find /var/www/myapp/storage/logs -name "*.log" -type f -mtime +7 -delete
关键点：
立即学习“PHP免费学习笔记（深入）”；
-
-mtime +7表示“修改时间超过 7 天”，比按文件名解析日期更可靠 - 别用
rm -f storage/logs/*.log—— 如果无匹配文件，shell 会字面传入*.log，导致误删当前laravel.log - 如果日志路径被软链到其他分区（如挂载的 SSD），
find仍有效；但log:clear可能因路径解析失败而静默跳过
日志体积爆炸时，先查源头再清理
频繁清日志治标不治本。常见诱因：
-
APP_DEBUG=true在生产环境开启，导致大量异常堆栈刷屏 - 循环中调用了
Log::info()或未捕获的Exception被重复抛出（比如中间件里没 catch 的 DB 连接失败） - 第三方包（如
spatie/laravel-backup）的日志级别设为debug，备份过程每秒打一条
临时缓解可用 tail -n 100 storage/logs/laravel.log | grep -E "(ERROR|CRITICAL|Exception)" 快速定位高频错误；长期要改 config/logging.php 中对应 channel 的 level，或加条件日志（如 Log::channel('stack')->when($condition, fn($log) => $log->error(...))）。
真正麻烦的是日志文件被进程锁住、或磁盘 inodes 耗尽（小文件太多），这时候删完也立刻涨回来——得先停服务、检查 error_log 配置、再看应用层有没有漏关的 stream handler。
