高并发下file_put_contents和error_log会静默丢日志，因锁机制阻塞超时且不报错；应使用Monolog+RotatingFileHandler配合useLocking=true、自定义结构化formatter、独立channel、ext4 ordered挂载及chattr+a防护，确保审计日志原子写入不丢失。
高并发下直接用 file_put_contents 必丢日志
不是性能差，是根本不可靠。PHP 的 FILE_APPEND | LOCK_EX 在 10+ 并发写入时会排队阻塞，超时请求直接放弃写入，error_log() 也一样——它底层也是文件追加，没做缓冲或重试。更糟的是，锁失败不报错，只静默丢弃，你根本不知道少了哪几条。
- 每条审计日志必须原子写入，不能依赖「应用层重试」——操作已发生，重试逻辑本身可能重复触发风险动作
-
flock()不适合审计场景：锁粒度粗（整个文件），且进程崩溃后锁可能残留，导致后续写入永久挂起 - Web 服务器（如 PHP-FPM）worker 进程复用时，
fclose()不一定及时触发，缓冲区日志可能滞留在内存里随进程回收而丢失
用 Monolog + StreamHandler 但必须绕开默认陷阱
Monolog 本身不丢数据，但默认配置会丢——关键在 handler 初始化和 formatter 设置。
- 必须显式设置
StreamHandler的$useLocking = true参数，否则并发写仍会挤成一行：new StreamHandler('/var/log/myapp/audit.log', Logger::INFO, true) - 禁用
LineFormatter中的%context%直接输出，它对数组只转成字符串"Array"，审计需要结构化字段。改用自定义 formatter 提取user_id、action、target_id等固定键 - handler 要绑定独立 channel，比如
new Logger('audit')，避免和 debug 日志混在一起，防止Logger::DEBUG级别日志冲垮磁盘
真正防丢的核心是「异步落盘 + 原子提交」
审计日志不是越快写越好，而是越确定写成功越好。同步刷盘代价高，但完全异步又不可靠。折中方案是：内存缓冲 + 定时强制刷写 + 文件系统级保障。
- 用
RotatingFileHandler替代StreamHandler，它自带缓冲和自动 flush 机制，且支持按大小/天数轮转，避免单文件过大卡 I/O - 日志路径必须挂载为
data=ordered或journal=writeback的 ext4 分区，禁用noatime外的激进优化，确保 write() 系统调用返回即落盘 - 配合系统级防护：
chattr +a /var/log/myapp/audit.log，只允许追加，防止被篡改或清空；用logrotate配置copytruncate而非create，避免轮转瞬间丢失正在写入的日志
审计日志丢了比功能出错更危险
它不会让服务崩，但会让安全事件彻底失察。比如连续 5 次登录失败没记下来，你就发现不了暴力破解；admin_role_grant 操作缺失，权限扩散就无法回溯。这些不是「偶尔少几条」的问题，而是审计链断裂——整条证据链失效。所以宁可让请求慢 20ms，也不能接受日志写入的任何不确定性。
立即学习“PHP免费学习笔记（深入）”；
