并发请求下TraceID丢失或重复，根本原因是HTTP生命周期与队列/异步执行天然割裂，必须手动透传而非依赖request()或中间件自动注入。
并发请求下 TraceID 会乱或丢失，不是 Laravel 的 bug，而是 HTTP 生命周期和队列/异步执行天然割裂导致的——必须手动透传，不能依赖 request() 或中间件自动注入。
为什么并发请求里 TraceID 经常是 null 或重复
HTTP 请求进来的那一刻，你用 Str::uuid() 生成了 $traceId，也塞进了 request()->attributes，日志看着都对。但一旦触发并发行为（比如 dispatch(new ProcessOrder($order, $traceId)) + Http::post(...) + DB::transaction(...) 套娃），问题就来了：
- 队列任务在新进程运行，
request()根本不存在，$traceId不显式传入就彻底消失 - 协程或
Http::pool()底层可能复用线程/连接，MDC 或自定义上下文不会自动继承 - 多个并发任务共用同一个
$traceId变量（比如闭包里捕获外部变量），结果所有日志都打上同一个 ID - Log::withContext() 只作用于当前 logger 实例，跨 channel（如
stackvssqs）或子进程不生效
Laravel 中安全透传 TraceID 的三种实操路径
别碰全局静态变量、别信 app('request') 在队列里还能用、也别在 handle() 里临时 request()->merge() —— 这些都会在高并发下翻车。可靠做法只有这几种：
- 队列任务：构造函数强制接收
$traceId，并在handle()开头立刻调用Log::withContext(['trace_id' => $this->traceId])；若用了自定义日志处理器（如AddTraceIdProcessor），需确保它 fallback 到$GLOBALS['current_trace_id']而非只查 request - HTTP 并发调用（
Http::pool()）：每个请求单独加 header，例如Http::asJson()->withHeaders(['X-Trace-ID' => $traceId])->post(...)；后端服务才能继续向下传递，否则链路在这里就断了 - 数据库事务内嵌逻辑（如 Observer、模型事件）：不能依赖
request()，得从当前上下文“带进来”——比如在控制器里把$traceId存进DB::transaction()的 closure 参数，或用app()->bind('current_trace_id', fn() => $traceId)注册瞬时绑定（注意生命周期）
Logback/Log4j 用户注意：Laravel 日志格式要对齐 MDC 键名
如果你的 Laravel 应用和 Java 服务共用同一套日志平台（比如阿里云 ARMS 或 ELK），且 Java 端用的是 %X{EagleEye-TraceID}，那 Laravel 就不能随便写 %X{trace_id} —— 键名不一致，日志平台无法聚合。
- Monolog 默认不支持 MDC 式键值注入，得靠
tap处理器往$record['extra']塞字段，但平台侧解析时认的是MDC.get("EagleEye-TraceID")，不是 extra - 解决办法：改用
monolog/formatter的LineFormatter自定义 pattern，并在tap处理器里手动 set$_SERVER['EagleEye-TraceID'] = $traceId（PHP 8.1+ 支持），再让 formatter 读这个 superglobal - 更稳的方式：统一用
X-Trace-ID请求头作为源头，在所有服务（包括 Laravel）的日志 pattern 里都写%X{X-Trace-ID}，避免跨语言键名冲突
最容易被忽略的坑：测试环境能跑通，线上必丢 TraceID
本地 php artisan serve 是单进程，request() 和日志上下文看起来“自动延续”；但线上用 php-fpm + queue:work --daemon + supervisor，每个环节都是独立生命周期。哪怕你写了 dispatchSync()，只要没显式传 $traceId，队列 worker 启动后第一次 handle 就是 null。真正上线前，务必在日志平台搜 trace_id: null 或 trace_id: unknown，而不是只看控制台输出是否正常。
