PHP 8.3日志过大核心在配置与策略而非版本，需三步解决：先用php -i/grep/du定位真实日志路径和大小；再用>或truncate清空正在写入的文件（禁用rm）；最后配logrotate启用size、copytruncate等关键项，并调低log_level、禁用catch_workers_output从源头减量。
PHP 8.3 日志过大，核心问题不在版本本身（8.3 没新增日志机制），而在于配置、写入行为和归档策略。直接删文件可能白忙活——空间不释放、新日志写不进、监控告警照旧。关键要分三步走：先定位源头，再安全清空/轮转，最后堵住“漏水点”。
一、快速定位日志来源和真实大小
别猜路径，用命令确认：
- 查 PHP 主错误日志位置：php -i | grep "error_log"（看 CLI 场景）或检查 Web 服务器配置（Nginx 的 fastcgi_param PHP_VALUE、Apache 的 php_admin_value error_log）
- 查 PHP-FPM 错误日志：grep -E "^(error_log|access.log)" /etc/php-fpm.d/www.conf
- 查是否写到 syslog：grep "syslog" /etc/php-fpm.d/www.conf 或 php -i | grep log_errors；若指向 syslog，实际日志由 rsyslog 控制，要去 /etc/rsyslog.d/ 查配置
- 看哪个文件真占空间：du -sh /var/log/php* /var/log/*error* 2>/dev/null | sort -hr | head -5
二、安全清理正在写入的日志文件
如果日志文件还在被 PHP-FPM 或 Web 服务持续追加，rm 就等于埋雷——进程仍持有句柄，磁盘空间不会释放，且新日志可能因 inode 变更失败。
- 推荐清空内容（保留文件+权限+inode）：> /var/log/php-fpm/www-error.log 或 truncate -s 0 /var/log/php-fpm/www-error.log
- 若需重载日志（如 PHP-FPM 支持）：kill -USR2 $(cat /var/run/php-fpm.pid)，它会自动 reopen 日志文件
- 验证是否生效：lsof +D /var/log/php-fpm/ 2>/dev/null | grep deleted —— 如果有输出，说明还有进程在往已删文件写，得重启服务
三、用 logrotate 实现自动轮转（生产环境必须项）
手动清是救急，logrotate 才是防复发的正解。常见配置陷阱是只写了 daily 却没设 size 和 copytruncate，导致大流量下单个日志一天就破 G。
立即学习“PHP免费学习笔记（深入）”；
- 编辑 /etc/logrotate.d/php-fpm（或自定义名），确保含以下关键项：
- size 100M：按大小触发，比 daily 更靠谱
- copytruncate：必须加！先拷贝再清空原文件，不中断写入
- rotate 7：保留最近 7 个归档，别设太大
- create 640 www-data www-data：保证新日志权限正确，否则 PHP 写失败
- compress：自动 gzip 压缩归档，省空间
- 配完测试：logrotate -d /etc/logrotate.d/php-fpm（-d 是 debug 模式，看是否识别成功）
四、从源头减少日志量（治本）
日志爆满常是代码或配置问题的信号。PHP 8.3 不自带限流，但可通过配置大幅降噪：
- 调低 PHP-FPM 错误级别：log_level = warning（在 www.conf 中），关掉 notice/debug 级别
- 禁用 worker 输出捕获：catch_workers_output = no，避免 echo/var_dump 跑进错误日志
- 检查是否重复记录：php -i | grep -E "(error_log|log_errors)"，确认没同时开启 php_admin_flag[log_errors] = on 和 php_admin_value[error_log]
- Laravel/ThinkPHP 等框架日志：查其配置（如 config/logging.php），关闭 debug 模式或调整 Monolog 的 RotatingFileHandler 保留天数
