直接 rm 正在写入的日志文件会导致磁盘空间不释放，因进程仍持有文件句柄；应使用 > 或 truncate 清空内容，配合 logrotate 的 size、copytruncate 等关键配置，并用精准 find 命令清理归档。
日志文件太大，直接 rm 会出问题吗？
会。如果 PHP 正在向一个日志文件（比如 /var/log/php-fpm/www-error.log）持续写入，直接 rm 删除后，进程仍持有该文件的句柄，磁盘空间不会释放——文件虽“消失”，但实际还在占用空间，直到进程重启或重载。
正确做法是清空内容而非删除文件：
-
> /var/log/php-fpm/www-error.log（最轻量，推荐） -
truncate -s 0 /var/log/php-fpm/www-error.log（语义更明确） - 避免
rm && touch或重定向到新文件再 mv，这会改变 inode，可能触发某些监控或 logrotate 的异常判断
logrotate 配置里哪些参数最容易被忽略？
很多用户配了 logrotate 却发现日志还是爆满，问题常出在没启用 copytruncate 或没设 size。
关键配置项说明：
立即学习“PHP免费学习笔记（深入）”；
-
size 100M：比daily更精准，按大小轮转，适合高流量站点 -
copytruncate：必须加！它先拷贝日志，再清空原文件，不中断 PHP 写入 -
rotate 7：保留最近 7 个归档，别设太大，否则find /var/log -name "*.log.*" -mtime +30这类清理脚本容易漏掉 - 别漏掉
create 640 www-data www-data，否则新日志权限不对，PHP 可能写失败
PHP-FPM 自身有没有日志限流机制？
没有内置“自动截断”或“最大行数限制”，但可通过配置降低日志量源头：
-
log_level = warning（在www.conf中），把notice和debug级别关掉，减少 80%+ 日志 -
catch_workers_output = no：关闭 worker 标准输出捕获，避免echo/var_dump污染错误日志 - 检查是否误开了
php_admin_flag[log_errors] = on+php_admin_value[error_log]双重记录，导致重复写入
注意：error_log 指向 syslog 时，日志由 rsyslog 控制，此时要查 /etc/rsyslog.d/50-default.conf 而非 PHP 配置。
用脚本定时清理，find 命令怎么写才安全？
别用 find /var/log -name "*.log" -mtime +7 -delete —— 它会删掉正在写的主日志文件（如 php-fpm.log），不是只删归档。
安全写法只匹配带数字/日期后缀的归档：
find /var/log -name "php*.log.[0-9]*" -mtime +30 -delete find /var/log -name "php*.log.[0-9][0-9][0-9][0-9]-[0-9][0-9]-[0-9][0-9]" -mtime +30 -delete
加 -type f 和 -print0 | xargs -0 更稳妥，尤其路径含空格时。执行前先用 -print 测试匹配结果。
真正麻烦的是混合部署环境：Nginx 错误日志、PHP-FPM 访问日志、应用层 Monolog 文件可能都在同一目录，靠名字区分不牢靠——这种场景建议按服务拆分日志目录，从根上避免误删。
