PHP 日志文件一旦持续膨胀，最直接的后果就是磁盘空间告警，进一步还可能拖慢业务机器的读写表现。在 CentOS 环境里，这类问题通常不难处理，关键是先分清“怎么清旧日志”和“怎么减少新日志继续暴涨”。下面按常见场景拆成三种办法，既能应急清理，也能补上长期维护策略。
用 logrotate 做日志轮转，适合长期托管
如果希望后续基本不用手工介入，最稳妥的方式还是交给 logrotate。它的作用是按周期切分日志、保留有限份数、压缩旧文件，并在条件不满足时跳过处理，比较适合线上环境长期运行。
在 CentOS 7 及以上版本中，logrotate 通常已经默认安装，相关配置文件放在 /etc/logrotate.d/ 目录下。如果系统里没有现成的 PHP 日志规则，可以自己创建一个文件，例如 /etc/logrotate.d/php。
/path/to/your/php/log/*.log {
daily
rotate 7
compress
missingok
notifempty
create 640 root adm
}这组配置对应的含义比较明确：
daily：每天轮转一次；rotate 7：保留最近 7 份旧日志；compress：轮转后的旧日志自动用 gzip 压缩；missingok：日志不存在时不报错；notifempty：空日志不处理；create 640 root adm：轮转后创建新日志，并设置权限、属主和属组。
这类方式的优势在于，它解决的不是一次性清理，而是“以后还会不会继续撑满磁盘”的问题。对于已经稳定运行的 PHP 服务，这通常是优先级最高的处理方案。
临时腾空间时，手动压缩和删除更直接
如果当前机器已经接近满盘，或者你只是想先快速把历史日志处理掉，手动清理会更直接。原文给出的做法是先压缩，再删除原始日志文件：
gzip /path/to/your/php/log/*.logrm /path/to/your/php/log/*.log这种方式适合应急场景，执行快、见效也快。但要注意，它本质上只是“这一次”把日志清掉，并没有建立后续保留策略。如果业务还在持续产生日志，空间问题很可能很快再次出现。
因此，手动处理更适合作为短期止血手段。若不想每次都重复执行这两条命令，可以把它们加入 cron 定时任务里，至少先实现周期性清理。只是从维护成本看，长期仍建议切回 logrotate 这样的标准方案。
从源头减量：调整 PHP 日志级别
有些服务器日志过大，并不只是因为没清理，而是 PHP 本身记录得过多。比如通知、严格模式提示、废弃警告都写进日志时，文件增长会非常快，尤其是旧项目或兼容性问题较多的环境。
这时可以检查 php.ini，重点关注 error_log、log_errors 和 error_reporting 配置。原文示例如下：
error_log = /path/to/your/php/log/php_error.log
log_errors = On
error_reporting = E_ALL & ~E_NOTICE & ~E_STRICT & ~E_DEPRECATED这表示继续开启错误日志，但在记录范围上做收缩：保留错误相关信息，同时排除 E_NOTICE、E_STRICT 和 E_DEPRECATED。这样做的核心目的，不是完全关闭日志，而是减少那些对排障价值不高、却会大量刷屏的内容。
修改完成后，还需要重启 PHP 服务，否则新配置不会生效。这里的判断标准也很简单：如果你的日志主要被大量提示类信息占满，那么只清理旧文件是不够的，必须同时把记录级别调低，才能真正控制后续增长速度。
三种办法怎么选
如果你面对的是线上长期运行的 CentOS 服务器，优先考虑日志轮转，因为它能把保留周期、压缩和权限一次性管起来；如果当前最紧迫的问题是磁盘马上打满，先手动压缩和删除能更快腾出空间；如果日志增长的根因在于 PHP 记录过细，就要同步调整 error_reporting，从源头减少无效输出。
更实际的做法通常不是三选一，而是组合使用：先手动清理释放空间，再补上 logrotate 规则，最后根据业务需要收紧 PHP 日志级别。这样既能解决眼前的问题，也能避免日志文件很快再次失控。
