并发日志需确保上下文隔离与事务一致性：Log::info() 无请求上下文故查不到用户ID；IP应取REMOTE_ADDR；用户ID仅在auth()->check()为true时提取；审计日志须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 被代理头覆盖、登录事件时机错位——这些都不会报错，只会让审计链条在关键节点静默断裂。
