确认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 级日志。
-
tail -f /var/log/php-error.log实时观察是否还有新行涌入，比看磁盘空间更直接 - 检查
php.ini中log_errors和error_log是否启用，某些环境误开log_errors = On但error_log指向一个不可写路径，PHP 会退回到stderr，而 Web 服务器（如 Nginx）可能把 stderr 合并进 access log，造成日志膨胀假象 - 用
journalctl -u php*-fpm -n 50查看 FPM 自身错误，有时子进程崩溃反复重启，导致日志句柄泄漏+重复写入
用 stat 和 inotifywait 做轻量级清理后核验
适合 CI/CD 部署后或运维巡检时快速确认：日志文件是否真的被轮转/截断，而不是仅改名。
立即学习“PHP免费学习笔记（深入）”；
- 清理前记下当前日志的 inode：
stat -c "%i" /var/log/php-access.log - 触发
logrotate -f /etc/logrotate.d/php后再查 inode，若变了，说明是 rename 方式轮转；若不变但大小为 0，说明是copytruncate成功 - 用
inotifywait -m -e create,move_self /var/log/监听目录，可直观看到php-access.log.1是否生成、php-access.log是否被move_self（即被重命名）
SIGHUP 或 USR1，导致轮转后仍往旧文件写——哪怕 logrotate 报告成功，磁盘空间也不会释放。核验必须落到进程行为和 inode 变化上，不能只信文件列表。 
