ThinkPHP 6 需手动在请求入口（如中间件）用 bin2hex(random_bytes(8)) 生成 TraceId 并设为日志上下文，HTTP 调用需手动透传 header，异步任务需显式传递，Swoole 等常驻进程须每次请求重设上下文。
ThinkPHP 6 如何生成并透传 TraceId
TP6 默认不生成 TraceId，得自己加。最稳妥的方式是在请求进入时（AppInit 或中间件）生成一个唯一 ID，并存入容器或请求上下文里。
推荐用 bin2hex(random_bytes(8))，比 uniqid() 更抗并发、无时间依赖，也避免纳秒级重复风险。
- 别在控制器里生成——可能被多次调用，导致同个请求多个
TraceId - 别用
session_id()或cookie值——前端不可控，且跨服务无法透传 - 如果用了 Nginx，可通过
proxy_set_header X-Trace-ID $request_id;提前注入，但 TP 需主动读取$request->header('x-trace-id')并 fallback 生成
如何把 TraceId 写进日志上下文
TP6 日志驱动支持上下文参数，但默认不自动注入。关键不是“写日志”，而是“让每条日志都带当前请求的 TraceId”。
最直接的办法是重写 think\log\driver\File 的 write() 方法，或更轻量地：在日志处理器中统一追加上下文。
立即学习“PHP免费学习笔记（深入）”；
- 在
app/common.php或中间件里，调用Log::setContext(['trace_id' => $traceId])——注意这是全局静态上下文，需确保每次请求单独设置 - 若用 Swoole 或常驻进程，必须在每次请求开始时清空/重设上下文，否则会串到下一个请求
- 自定义日志 formatter 时，记得从
Log::getContext()取值，而不是硬编码或从Request实例里临时读
跨服务调用时怎么透传 TraceId
HTTP 调用（比如用 think\facade\Http 或 Guzzle）必须手动加 header，TP 不会自动帮你带上当前请求的 TraceId。
常见错误是只传了 X-Trace-ID，但下游服务没读、或读错了 key 名，结果链路断在第二跳。
- 发请求前，从当前上下文中取
TraceId：Log::getContext()['trace_id'] ?? '' - Guzzle 示例：
Http::withHeaders(['X-Trace-ID' => $traceId])->get(...) - 如果下游是 Java/Spring Cloud，它可能期望
traceId（小写）或uber-trace-id，得按对方约定对齐，不能只图自己顺手 - 异步任务（如
think\queue\Job）要显式把TraceId作为参数传进去，队列消费时再塞回日志上下文
为什么日志里还是看不到 TraceId？几个典型漏点
不是代码没写，而是执行时机或作用域错了。尤其在 TP6.1+ 的多应用模式或命令行场景下，容易误判“当前请求上下文”是否存在。
查问题先盯三点：日志是否真走了你改的逻辑、TraceId 是否为空、上下文是否被覆盖。
-
Log::setContext()必须在日志记录前调用，比如放在中间件handle()开头，而不是结尾 - 使用
Log::debug()等方法时，如果传了第二个参数（上下文数组），会覆盖全局上下文——此时得手动合并：Log::debug('msg', array_merge(Log::getContext(), $extra)) - TP 的
console命令默认没有 HTTP 请求上下文，TraceId得靠命令参数或环境变量注入，不能假设Request::instance()一定存在
链路追踪真正卡住的地方，往往不是生成 ID，而是上下文生命周期管理——它既不能太早（还没进请求），也不能太晚（日志已刷出）。
