根本原因是未为审计日志单独配置channel。PHP默认日志函数、Monolog和ThinkPHP均将审计事件与错误混写同一文件，导致grep漏检、tail噪音大；须显式指定独立channel并配置专属路径，同时确保日志含user_id、action、target_id、status、timestamp等关键字段，方可精准审计。
为什么 audit.log 和 error.log 总混在一起
根本原因是没给审计日志单独开 channel。PHP 默认的 error_log()、Monolog 的默认 single 渠道、ThinkPHP 的 Log::write() 都往同一个文件写，比如 /var/log/php/error.log 或 runtime/log/202607.log。审计事件（如 user_password_change）和 PHP 致命错误（Fatal error: Class 'XXX' not found）挤在同一行，grep user_password_change 会漏掉，tail -f 又全是无关噪音。
用独立 channel 隔离审计日志（Monolog / ThinkPHP / 原生）
核心动作就一条：所有审计日志必须显式指定渠道名，且该渠道配置独立路径或表。
- Monolog：创建
$auditLogger = new Logger('audit')，绑定StreamHandler('/var/log/myapp/audit.log')，写日志时调$auditLogger->info()—— 别用$logger->info() - ThinkPHP 6：在
config/log.php里定义'admin'渠道，中间件中必须写Log::channel('admin')->info()，否则全进single - 原生 PHP：别用
error_log()，改用file_put_contents('/var/log/myapp/audit.log', $line, FILE_APPEND | LOCK_EX)，但注意并发锁问题（见下一条）
并发写 audit.log 卡死或丢日志怎么办
LOCK_EX 是阻塞锁，10 个后台操作同时触发，9 个在等锁，响应延迟飙升，还可能因超时导致日志丢失。这不是小概率事件，是高并发下的确定性问题。
- 生产环境禁用
file_put_contents(..., LOCK_EX)直写方式 - 改用 Monolog 的
RotatingFileHandler或StreamHandler，它内部用fopen('a')+fflush()，比手动锁更轻量 - 更高要求场景：审计日志先写 Redis List 或 Kafka，再由独立 worker 落库或落文件，彻底解耦
- 路径权限必须设对：
chown www-data:www-data /var/log/myapp/，否则LOCK_EX失败静默丢日志
怎么查才不漏掉关键审计事件
日志分开了，但查法不对照样白搭。审计日志不是用来“翻着看”的，而是要能精准定位「谁、什么时间、对什么做了什么」。
立即学习“PHP免费学习笔记（深入）”；
- 每条日志必须含
user_id（未登录则记ip）、action（如data_delete）、target_id（如订单号12345）、status（success/failed）、timestamp - 用
awk快速提取失败删除：awk '/data_delete.*failed/ {print $1,$2,$NF}' /var/log/myapp/audit.log - 别信
$response->getCode()判断成败 —— ThinkPHP 里 500 错误也返回 200；得捕获异常或解析响应体里的code字段 - 日志行末必须有换行符，否则
grep匹配不到，tail -f显示错位
真正难的不是分开写，是让每条审计日志自带上下文、可被机器精准提取。少一个 target_id，查到删错数据就只能靠猜。
