logrotate 是最稳的 PHP 日志切割方案，需将配置文件置于 /etc/logrotate.d/ 下，严格匹配日志路径，必配 create 和 copytruncate，建议加 postrotate 发送 USR2 信号通知 PHP-FPM 重开日志文件。
直接用 logrotate 配置 PHP 日志切割是最稳、最省心的方案，不需要改代码、不依赖 PHP 进程重启，只要配对路径和权限，就能每天自动归档压缩并清理旧日志。
logrotate 配置文件放哪、名字怎么起
必须放在 /etc/logrotate.d/ 目录下，文件名任意（比如 php-fpm 或 myapp-php），但不能和已有配置重名。系统会自动加载该目录下所有文件，无需手动注册或 reload 服务。
- 路径错误是常见失败原因：确认你的 PHP 日志真实路径，比如
/var/log/php-fpm/www-error.log或/www/wwwlogs/xxx.php.error.log，配置里写的路径必须完全一致（支持通配符*，但别写错层级） - 不要把配置写进
/etc/logrotate.conf主文件——它只定义全局默认值，自定义规则应独立成文件 - 配置文件权限建议保持默认（644），属主 root，logrotate 运行时以 root 权限读取
关键参数必须写全，尤其 create 和 copytruncate
少写一行就可能让轮转后新日志写不进去，Nginx 或 PHP-FPM 报 Permission denied 或干脆静默丢日志。
-
create 640 www-data adm（Ubuntu）或create 640 www www（宝塔）：轮转后新建日志文件，并设好权限和属主属组；缺了这行，新日志文件会是 root:root，PHP 进程无权写入 -
copytruncate：复制当前日志内容后清空原文件，避免重启 PHP-FPM；没有它，rename会失败（进程正占用文件句柄），旧日志继续膨胀 -
missingok+notifempty：防止日志还没生成或为空时报错中断整个轮转流程 -
compress+delaycompress：先压缩上一轮归档（如.1），保留.1.gz而不是.1，节省空间
测试配置是否生效，别等明天才发现问题
别靠“明天看有没有 .1 文件”来验证，要用 logrotate 自带调试模式当场检查语法和路径逻辑。
立即学习“PHP免费学习笔记（深入）”；
- 先 debug：运行
sudo logrotate -d /etc/logrotate.d/php-fpm，看输出里有没有error:或skipping提示；重点确认 “considering log file” 后面的路径是否是你的真实日志路径 - 再强制跑一次：用
sudo logrotate -f /etc/logrotate.d/php-fpm真实触发轮转，观察原日志是否被重命名（如变成www-error.log.1）、新日志是否生成且可写（ls -l看权限和属主） - 检查 PHP 进程是否还在写：
tail -f /var/log/php-fpm/www-error.log，有新内容进来才算真正成功；如果停了，可能是copytruncate没生效，或 PHP-FPM 没权限写新文件
PHP-FPM 场景下必须加 postrotate 通知重开日志
仅靠 copytruncate 不够——PHP-FPM 的 worker 进程仍持有旧文件句柄，部分日志可能继续写进已归档的 .1 文件里，导致日志分散、漏记录。
- 在配置块里加上
sharedscripts和postrotate脚本，例如：
postrotate
if [ -f /var/run/php-fpm/php-fpm.pid ]; then
kill -USR2 `cat /var/run/php-fpm/php-fpm.pid`
fi
endscript
USR2 是 PHP-FPM 的平滑重载信号，会让所有 worker 关闭当前日志句柄并重新打开新日志文件/var/run/php-fpm/php-fpm.pid 或 /run/php/php8.2-fpm.pid），不同版本路径不同www-data 用户可能没权限发 kill，所以脚本里不用 sudo，而是靠 logrotate 以 root 执行保证权限最容易被忽略的是：宝塔面板站点日志默认不在任何 logrotate 配置里，得手动建 /etc/logrotate.d/bt-site；而 PHP-FPM 的 postrotate 如果 PID 路径写错或服务没启用，USR2 就发不出去，日志还是乱写。动手前先 ps aux | grep php-fpm 确认进程和 PID 文件是否存在，比事后排查快十倍。
