删错日志文件会导致PHP调试信息永久丢失，因error_log、var_dump及框架日志是偶发问题的唯一证据；应按时间或大小轮转清理，避免无差别删除，分离调试与运行日志，并优先使用IDE断点调试。
清理 logs 时删错文件会导致调试信息永久丢失
PHP 调试严重依赖 error_log、var_dump 输出、框架日志（如 Laravel 的 storage/logs/laravel.log）或自定义 file_put_contents('debug.log', ...)。如果清理脚本无差别删除所有 *.log 或清空整个 logs/ 目录，正在写入的调试日志可能被截断，且无法回溯——尤其是线上复现困难的偶发问题，日志就是唯一证据。
实操建议：
- 绝不直接
rm -rf logs/或unlink($file)批量删目录 - 按时间保留：只删
7天前的*.log，用find logs/ -name "*.log" -mtime +7 -delete - 按大小轮转：用
logrotate配置size 10M+rotate 5，避免单个日志膨胀阻塞写入 - 调试期间临时停用自动清理 cron，或给调试日志加独立前缀（如
debug_20241015.log）并排除在清理规则外
PHP 内置 error_log 不受文件清理影响，但需确认输出目标
error_log() 默认行为取决于 php.ini 中 error_log 配置项：它可能写到系统 syslog、Apache/Nginx 错误日志，或某个具体文件（如 /var/log/php_errors.log）。如果你只清理项目内的 logs/ 目录，而 error_log() 实际写入的是系统路径，那调试输出根本不会被删——但你也可能根本没看到它。
检查和加固方法：
立即学习“PHP免费学习笔记（深入）”；
- 运行
php -i | grep error_log确认当前生效的error_log路径 - 在调试脚本开头加
error_log("DEBUG START: " . print_r($_REQUEST, true), 3, "/tmp/php_debug.log");，强制指定可管控的文件 - 若用
error_log($msg)无参数，默认走stderr，在 CLI 模式可见，在 Web 模式下通常被 Web 服务器丢弃——这点极易被忽略
框架日志（Laravel/Symfony）有内置清理机制，别重复造轮子
Laravel 的 php artisan log:clear 和 Symfony 的 bin/console monolog:clean 并非简单 rm，它们会先确保当前日志文件未被进程锁住（比如正在写入的 laravel.log），再安全重命名或清空内容。手写 shell_exec("rm logs/*.log") 在高并发场景下可能导致日志写入失败甚至 PHP 报 failed to open stream: No such file or directory。
