ThinkPHP如何配置安全日志的自动轮转机制【安全】

在处理ThinkPHP的日志管理时，一个常见需求是配置安全日志的自动轮转，以防止日志文件无限膨胀。但这里有个关键点需要先明确：ThinkPHP并没有为安全日志设立独立的通道或驱动。所有的日志事件——包括登录失败、权限拒绝、或潜在的注入攻击信息——最终都会汇总到统一的日志文件中。所谓的安全日志轮转，本质上是对整个日志目录进行轮转策略的配置。

这意味着，你无法期望通过添加一个简单的配置项就能实现对安全事件的单独切割与归档。轮转机制是路径和文件级别的，它不会去解析日志内容来区分哪些是安全事件。

为什么直接配置“安全日志”轮转行不通

真相是，ThinkPHP的日志体系中没有 SecurityLog 这个类，也没有名为 security 的日志通道。无论你手动写入 Log::error('Login failed from IP: ' . $ip) 还是其他任何监控事件，它们都一并走 log 驱动，最终落在 runtime/log/ 目录下的 .log 文件中。即便你自以为已经区分了安全日志，实际上它们依然与其他日志混杂在一起。

• 你不能在 config/log.php 里写 'type' => 'SecurityRotate'——这个驱动不存在，框架也不会识别。
• 无论是 RotatingFileHandler 还是系统级的 logrotate，它们都只认文件路径和命名规则，不执行内容解析。
• 想用正则从日志里提取“安全事件”再另存为单独文件，那是应用层逻辑，不在轮转机制的管辖范围内。

真正可行的轮转方案只有两类

要让包含安全事件的日志实现自动轮转，只有两条路可选，并且必须明确选择其中一条，不能混用。

第一条路：换用 ThinkPHP 自带的 Rotate 驱动。修改 config/log.php 中的 'type' => 'File' 为 'type' => 'Rotate'，并配置 'max_size' 或 'time_format'。这是最轻量、无需额外依赖的方式。

第二条路：使用系统级 logrotate。将 runtime/log/*.log 路径交给 Linux 的 logrotate 管理，通过 daily/size 加上 compress 实现切割压缩。这种方式更适合生产环境的统一运维。

二者互斥，不能同时启用，否则会导致日志双写或轮转冲突。一旦陷入这种状态，排查起来会非常头疼。

Rotate 驱动配置的几个关键陷阱

看起来只是改个 type 设置，但实际运行中常因下面这些细节导致失败：

• max_files 和 max_size 必须至少设一个。如果两者都未配置，Rotate 驱动会退化为 File 行为，根本不会触发轮转。
• 如果设置了 'time_format' => 'Y-m-d'，但服务器时区不是 Asia/Shanghai，日志会按 UTC 时间切割。白天写入的数据会被归到昨天的文件里，查找时很容易遗漏。
• runtime/log/ 目录权限必须为 755，确保 Web 进程有 write + execute 权限。否则轮转过程中 rename 操作会失败，旧文件删不掉，新文件也建不了。
• max_size 的单位是字节。写 10485760 表示 10MB，但如果误写成 10M 或 10MB，PHP 会当字符串处理，轮转失效。

logrotate 配置必须带 copytruncate

如果选择了系统级轮转，那么 /etc/logrotate.d/thinkphp 里这一行不能少：copytruncate。

原因很简单：ThinkPHP 的 PHP 进程持有日志文件的句柄。默认情况下，logrotate 会对文件进行移动（mv）后再新建，但 PHP 仍然在往原文件路径写入。结果就是新日志全部写进了被重命名的旧文件里，而新建的文件始终为空。

• copytruncate 会先复制文件内容，接着清空原文件。PHP 进程对此毫无感知，依然可以继续写入原路径。
• 必须搭配 create 640 www-data www-data（Ubuntu）或 create 640 apache apache（CentOS），否则清空后权限会丢失，下次写入会失败。
• delaycompress 要和 compress 一起使用，否则在 copytruncate 模式下，可能压缩一个刚刚被清空的文件。
• 测试命令不要只跑 sudo logrotate -d（这个只检查语法），一定要加 -f 强制执行一次：sudo logrotate -f /etc/logrotate.d/thinkphp。然后检查 runtime/log/ 目录是否生成了 xxx.log.1 或 xxx.log-20260625.gz。

真正困难的地方不在于配置本身，而在于确认日志最终写到了哪里、轮转后 PHP 进程是否还能正常追加内容、压缩后的文件权限是否合适。这些都需要动手验证，仅靠阅读文档是无法解决的。