Laravel并发日志设计详解

本文深入剖析了 Laravel 并发环境下日志设计的多重陷阱与精准解法：从 Log::info() 因缺失请求上下文而无法获取用户 ID，到 IP 必须取自 REMOTE_ADDR 以规避代理污染；从审计日志必须通过 afterCommit() 确保事务提交后写入以防断档，到高频日志表需强制 BTREE 索引、按月分表及字段长度收敛以对抗查询劣化；再到登录日志唯一可靠落点是 AuthenticatedSessionController@store 末尾——每一条都是线上真实踩坑沉淀出的硬核经验。这不是调优指南，而是防止审计链条在关键节点“静默断裂”的生存手册。

并发环境下直接同步写用户行为日志，大概率导致请求阻塞、事务丢失、IP 获取错误或日志漏记——这不是配置问题，是执行时机和上下文隔离没处理好。

为什么 Log::info() 在并发时查不到用户 ID

因为 Log::info() 本身不感知请求上下文，更拿不到 auth()->id()。在队列、定时任务、异步 HTTP 客户端（如 Guzzle）或中间件提前退出的场景下，auth() 返回 null 是常态，不是 bug。

• 别在 Formatter 里调 request()->ip() 或 request()->fullUrl()：每次日志写入都重建 Request 实例，QPS 超 20 就明显拖慢响应
• 真正可靠的 IP 来源是 request()->server('REMOTE_ADDR')，尤其在 Nginx + PHP-FPM 部署下，它绕过所有代理污染
• 如果必须记录用户 ID，只在控制器、中间件或事件监听器中，且确认 auth()->check() 为 true 后再提取

中间件里记录 POST/PUT/DELETE 日志要加 afterCommit()

很多操作发生在数据库事务内（比如订单创建 + 库存扣减），若日志写入和业务逻辑共用一个事务，一旦事务回滚，日志也跟着消失——审计就断档了。

• 不要用 ActivityLog::create(...) 直接插入
• 改用队列任务并显式声明 afterCommit()：LogAuditEvent::dispatch(...)->afterCommit()
• afterCommit() 确保只有当事务真正提交后，队列才开始执行；它比 DB::unprepared() 更安全，不破坏事务语义
• 该方法仅对 database/redis 队列驱动生效，sync 驱动无效（开发环境需切真实驱动测试）

高频日志表查询卡顿，光加索引还不够

即使加了 user_id 和 created_at 联合索引，单表超 80 万行后，WHERE user_id = ? AND created_at > ? 仍可能走全表扫描——MySQL 优化器有时会误判范围条件的选择性。

• 迁移中强制指定索引类型：$table->index(['user_id', 'created_at'], 'activity_user_time_idx')->using('BTREE');
• 对 action 字段高频筛选的场景（如只查 'deleted_post'），单独建 action_created_at_idx，避免联合索引失效
• 别等慢查询爆发再分表：上线前就规划按月分表，用视图聚合（如 CREATE VIEW activity_logs AS SELECT * FROM activity_logs_202605 UNION ALL SELECT * FROM activity_logs_202604;）
• 日志字段值长度要收敛：url 截断到 1024 字符，user_agent 限制 500 字符，避免 BLOB 类型拖慢索引效率

登录日志必须避开 Illuminate\Auth\Events\Login

这个事件在 session 写入前触发，auth()->user() 可能为空，尤其用了多守卫或自定义 provider 时。线上已有多起因监听该事件导致 30% 登录日志缺失的案例。

• 唯一可靠位置是 AuthenticatedSessionController@store 的末尾，在 return redirect()->intended() 之前
• 确保 session()->save() 已执行（Laravel 10+ 默认自动 commit，但自定义中间件可能干扰）
• 记录字段必须含 user_id、ip_address（用 request()->server('REMOTE_ADDR')）、login_at，三者缺一不可
• 别用模型观察者监听 User::saved —— 登录不改 User 表，纯属误触发

并发日志最危险的盲区不是性能，而是“你以为记了，其实没记”：事务未提交就写、队列任务没传 $userId、IP 被代理头覆盖、登录事件时机错位——这些都不会报错，只会让审计链条在关键节点静默断裂。

文中关于Laravel的知识介绍，希望对你的学习有所帮助！若是受益匪浅，那就动动鼠标收藏这篇《Laravel并发日志设计详解》文章吧，也可关注golang学习网公众号了解相关技术文章。