确认logrotate是否真正清理PHP日志，关键看旧日志是否停止写入且磁盘空间释放：检查当前日志inode是否变化或大小归零、lsof确认PHP进程未持有旧文件句柄、df与du对比验证空间释放、journalctl和tail实时观察写入行为。
怎样确认 logrotate 是否真正清理了 PHP 日志
直接看日志文件是否存在或大小是否归零，往往不准——因为 logrotate 默认用 copytruncate 或重命名方式处理，原文件句柄可能仍被 PHP-FPM 或 Apache 持有。验证重点不是“文件删没删”，而是“旧日志内容是否还在写入、磁盘空间是否释放”。
- 执行
ls -lh /var/log/php*.log*查看文件时间戳和大小，但注意：access.log.1这类归档文件存在是正常的，关键看access.log（当前活跃文件）是否被截断或重建 - 用
lsof -n -p $(pgrep php-fpm | head -1) | grep log检查 PHP 进程是否还持有着已轮转的日志文件（如access.log.1），若存在，说明它仍在往旧文件写，copytruncate未生效或配置漏 reload - 对比
df -h /var和du -sh /var/log/php*.log*，如果df显示空间未释放，但du总和很小，大概率是进程没释放句柄，需kill -USR1或重启 PHP-FPM
PHP 应用层日志（如 Monolog）如何验证清理结果
框架或自定义日志（如 Laravel 的 storage/logs/laravel.log）不走 logrotate，得靠应用自身策略或外部脚本清理。验证核心是：清理逻辑是否被执行、保留策略是否准确、是否误删正在写的日志。
- 检查清理命令是否带
--dry-run（如find storage/logs -name "*.log" -mtime +7 -delete改成-print先试跑） - 确认 PHP 进程没以
root身份运行却写日志到非 root 可删目录，否则crontab用www-data清理会因权限失败，日志越积越多 - Monolog 的
RotatingFileHandler默认按天轮转，但不会自动删除旧文件；若启用了$handler->setFilesToKeep(5)，需验证实际保留数是否严格 ≤5，注意它只在新日志创建时触发清理，不是定时任务
常见误判：明明跑了清理脚本，日志目录还是爆满
根本原因常不在“没清理”，而在“清了但没生效”或“边清边写得更快”。尤其当 PHP 错误日志开启 error_log = /var/log/php-error.log 且未配置 logrotate，又遇上无限循环报错，几秒就能写满 GB 级日志。
