PHP日志过大解决方法及优化技巧

PHP本身不提供日志大小限制与自动轮转功能，日志堆积风险需通过系统级工具（如logrotate或rotatelogs）统一管理，推荐将Web服务器和PHP-FPM的日志交由这些成熟守护进程按大小或时间轮转、压缩并保留指定份数；若必须在PHP中自控业务日志，则需谨慎实现文件大小检测、带时间戳的原子性归档及加锁清空，并严格规避并发写入和权限冲突问题——忽视权限配置、误用unlink或忽略PHP-FPM慢日志等细节，往往才是生产环境中磁盘被日志悄然占满的真正原因。

PHP 本身不直接管理日志文件大小

PHP 的 error_log() 函数默认只是把日志写进文件或系统 syslog，它不会自动轮转、压缩或删除旧日志。所谓“限制日志大小”，实际得靠外部机制或封装逻辑来实现，不是改几个 PHP 配置就能一劳永逸。

用 rotatelogs 或 logrotate 做系统级轮转（推荐）

Web 服务器（如 Apache/Nginx）产生的访问日志和错误日志，应优先交给系统工具处理，而非在 PHP 里硬编码判断文件大小。PHP 只负责“写”，轮转交给更可靠的守护进程。

• logrotate 是 Linux 标配，支持按大小（size 10M）、时间（daily）或两者结合轮转，还能配置压缩（compress）、保留份数（rotate 7）
• Apache 可配合 rotatelogs：在 CustomLog 中写成 CustomLog "|/usr/bin/rotatelogs -l /var/log/apache2/access_%Y%m%d.log 10M" combined
• 切忌让 PHP 进程自己去 unlink() 或 rename() 日志文件——多进程并发时极易出错，且无法保证原子性

如果必须用 PHP 自控日志大小，需手动检查 + 拆分

仅适用于自定义业务日志（比如 file_put_contents('app.log', ...)），且并发量低、可控场景。核心是：写之前查大小，超限时归档再清空。

• 用 filesize() 判断当前日志是否超过阈值（如 5MB），但注意返回 false 表示文件不存在或无权限
• 归档建议用 date('Ymd_His') 时间戳命名，避免冲突：rename('app.log', 'app.log.' . date('Ymd_His'))
• 归档后必须用 file_put_contents('app.log', '', LOCK_EX) 清空，不能只 fopen(..., 'w') 后不写内容——某些系统下可能残留 inode 占用空间
• 不要用 exec('rm old.log') 删除旧归档，容易被禁用或出错；改用 unlink() 并配合 glob('app.log.*') 找出并清理过期文件

PHP-FPM 错误日志和慢日志的配置项别漏掉

这些日志由 PHP-FPM 主进程管理，但默认不设大小限制，长期运行会悄悄膨胀。

• php-fpm.conf 中设置 error_log = /var/log/php-fpm-error.log 后，必须配套用 logrotate 管理该路径
• 慢日志 slowlog = /var/log/php-fpm-slow.log 同样需要轮转，否则一个卡住的请求就可能打满磁盘
• log_level = warning 可降低日志密度，但不能替代轮转——warning 级别仍可能高频输出

实际部署时，最常被忽略的是：日志路径权限没对齐，导致 logrotate 无法重命名或 PHP 进程无法写入新文件。轮转脚本和 PHP 运行用户（如 www-data）必须对日志目录有读写权限，且 SELinux/AppArmor 未拦截。

今天关于《PHP日志过大解决方法及优化技巧》的内容介绍就到此结束，如果有什么疑问或者建议，可以在golang学习网公众号下多多回复交流；文中若有不正之处，也希望回复留言以告知！