ThinkPHP 通过 think\Request 实例承载请求上下文，推荐使用 $request->withAttribute() 和 $request->getAttribute() 安全存取 trace_id 等数据；避免用 Config::set() 或 Session::set()，因其不满足请求隔离与并发安全；跨 HTTP 调用需手动注入 header；日志与队列任务须显式传递 trace_id。
ThinkPHP 本身没有内置的 RequestContext 或 context.Context 类似 Go 那样的结构化上下文对象，它的请求上下文本质是围绕 think\Request 实例展开的——这个对象在一次请求生命周期内是单例、可扩展、可携带属性的。中间件中“传递上下文”，核心不是透传一个独立 context 对象，而是**安全地往 Request 对象上挂载/读取数据，并确保后续环节（控制器、日志、HTTP 客户端）能一致访问**。
用 Request 对象自身承载上下文数据
ThinkPHP 的 $request 是可写入属性的，这是最直接、最符合框架习惯的方式：
- 在中间件中设置：
$request->trace_id = $id;或更规范地用$request->withAttribute('trace_id', $id) - 在控制器或其它地方读取：
$request->getAttribute('trace_id')或直接$request->trace_id - 该方式天然支持前置/后置中间件，且属性随请求对象自动流转，无需手动透传
避免依赖全局 Config 或 Session 存上下文
虽然 Config::set() 或 Session::set() 能临时存值，但存在明显风险：
-
Config::set()是应用级静态变量，多请求并发时可能互相覆盖（非线程/协程安全） -
Session依赖 Cookie 或服务端存储，纯 API 接口通常无会话，且不适用于异步任务或队列消费场景 - 它们脱离了请求生命周期管理，容易造成内存泄漏或上下文污染
跨 HTTP 调用时需显式注入 trace_id
Request 对象的属性不会自动带到下游 HTTP 请求中。调用第三方接口前，必须手动将 trace_id 注入 header：
立即学习“PHP免费学习笔记（深入）”；
- 封装统一的 HTTP 客户端（如基于 think\facade\Http），在发送前读取
$request->getAttribute('trace_id') - 自动添加 header：
['X-Trace-ID' => $traceId] - 若使用 Guzzle、curl 等原生客户端，务必在每次请求构造时显式设置，不能依赖中间件里的一次性读取
日志与异步任务需主动延续上下文
日志 formatter 和队列任务执行环境与当前 HTTP 请求隔离：
- 自定义日志处理器中，优先从当前 Request 实例（可通过容器解析或中间件传参获取）提取 trace_id
- 进队列前，把 trace_id 作为 job 参数显式传入，例如：
dispatch(new ProcessJob($data, $request->getAttribute('trace_id'))) - 协程或子进程场景下，同样需在启动时捕获并带入，不能假设上下文自动继承
