删log前须确认进程是否仍在写入，否则会导致磁盘空间不释放或新日志无法生成；应优先使用kill -USR2、清空文件或find批量清理，并验证权限、进程与框架配置。
直接删 log 文件前先确认进程是否还在写入
PHP 应用（比如 Laravel、ThinkPHP 或纯原生脚本）通常由 Web 服务器（Nginx/Apache）或常驻进程（php artisan queue:work、supervisord 管理的守护进程）写日志。如果直接 rm -f *.log，部分程序会因文件句柄未释放继续往已删除的 inode 写数据，磁盘空间不释放，且新日志可能无法生成。
- 查正在写日志的进程：
lsof +D /path/to/logs/ | grep deleted（Linux），看到类似php 1234 user 5w REG 253,0 1073741824 123456 /var/log/app/app.log (deleted)就说明它还在往已删文件写 - 稳妥做法是：先
kill -USR2（对支持重载日志的进程）或重启对应服务；若为普通文件写入，可先echo "" > app.log清空内容而非删除文件 - Web 服务器自身日志（如
access.log、error.log）需单独处理，和 PHP 应用日志不是一回事
用 find 按时间批量清理旧日志最常用
手动清理不等于一个个 rm，用 find 是标准操作，尤其当目录下有 app-2024-01-01.log、debug.20240101.log 这类带日期的文件时。
- 删 30 天前的所有
.log文件：find /var/log/myapp/ -name "*.log" -mtime +30 -delete - 删 7 天前的压缩日志（
.log.gz）：find /var/log/myapp/ -name "*.log.gz" -mtime +7 -delete - 加
-print先预览（安全习惯）：find /var/log/myapp/ -name "*.log" -mtime +30 -print -
-mtime +N表示“修改时间早于 N 天前”，不是“创建时间”；若日志是每日轮转但未改名，可能要用-ctime或结合-name正则匹配
Laravel / ThinkPHP 等框架日志不能只删文件
这些框架默认用 Monolog，日志路径在配置里（如 Laravel 的 config/logging.php），但更关键的是：它们可能启用日志轮转（RotateHandler）或异步写入（AsyncHandler）。手动删文件后若没清缓存、没触发重建，下次写日志可能报错或写入失败。
- Laravel：删完检查
storage/logs/下是否有残留的laravel.log.lock文件，有就rm掉 - ThinkPHP：确认
runtime/log/目录权限仍是www-data（或运行用户）可写，否则删完也无法生成新日志 - 所有框架：删完建议跑一次
php artisan config:clear（Laravel）或清空runtime/cache/（TP），避免配置/缓存残留干扰
清理后必须验证日志是否真能写入
删完不验证 = 白干。常见现象是磁盘空间降了，但新日志没产生，或 PHP 报 file_put_contents(/path/to/app.log): failed to open stream: No such file or directory 错误。
立即学习“PHP免费学习笔记（深入）”；
- 立刻触发一次日志写入：比如访问一个会打日志的接口，或在命令行执行
php -r "error_log('test log', 3, '/var/log/myapp/test.log');" - 检查文件权限：
ls -l /var/log/myapp/，确保目录属主是 Web 进程用户（如www-data），且有w权限 - 检查磁盘配额：
quota -u www-data（若有配额限制），或df -h /var/log看是否还有空间 - 注意 SELinux（CentOS/RHEL）：
ls -Z /var/log/myapp/，若上下文不对（如unconfined_u:object_r:var_log_t:s0缺失），需restorecon -Rv /var/log/myapp/
