thinkphp中请求id需通过全局中间件在应用初始化时生成并透传，统一注入request扩展属性和日志上下文，确保http入口→控制器→模型→日志全链路一致；严禁控制器内重复生成，swoole环境须每次请求重置；日志需配置context格式化输出；跨模块调用须手动传递id，避免依赖全局变量。
请求ID怎么在ThinkPHP里自动生成并透传
ThinkPHP本身不内置全局请求ID，但可以通过中间件+系统钩子实现统一注入。关键不是“加ID”，而是确保整个生命周期（HTTP入口→控制器→模型→日志）用的是同一个ID，否则链路就断了。
推荐做法：在应用初始化阶段通过think\App::beforeStart事件或全局中间件生成一次request_id，存进think\facade\Request的扩展属性，并同步写入Log::setRequestID()（5.1+）或手动注入日志上下文（6.x）。
- 别用
uniqid()单独调用——并发下可能重复，改用md5(uniqid(microtime(true), true))或Str::uuid()（需引入support包） - 不要在控制器里再生成一次ID，否则日志、DB查询、Redis操作拿到的ID就不一致
- 如果用了Swoole常驻内存，必须每次请求重置ID，否则会复用上一个请求的值
日志里怎么固定显示这个请求ID
ThinkPHP 6.x 默认日志处理器（think\log\driver\File）支持context字段注入，但不会自动带出request_id。得手动在日志配置里加json格式化逻辑，或者替换write方法。
最稳的方式：在app/middleware/LogRequestID.php中间件中，调用Log::setContext(['request_id' => $id])，并在config/log.php里把format设为'[{datetime}] [{level}] {message} {context}'。
- 5.1版本没有
setContext，得改think\log\driver\File::write()，在拼接日志前插入[request_id: xxx] - 别直接改框架源码，用
extend目录重写驱动类，避免升级覆盖 - 如果用了Monolog，要确认
Monolog\Processor\IntrospectionProcessor没干扰上下文字段顺序
跨模块调用时请求ID怎么不丢
模型查询、队列任务、HTTP客户端发起的子请求，都容易让request_id失效。核心原则：能传参不依赖全局变量，能序列化不靠闭包捕获。
例如调用Http::get()发下游接口时，必须手动加Header：['X-Request-ID' => $this->request->header('X-Request-ID', $this->request->id())]；队列任务里不能直接读Request::instance()，得在投递时把ID作为参数传进去。
- DB查询日志想带ID？给
think\db\Connection加after_query监听，在Log::record()里补context - Redis操作没ID？封装一层
Cache::tag()或用redis->setOption(Redis::OPT_PREFIX, $id.':')临时打标（慎用，仅调试） - 别信“自动继承上下文”的第三方日志包，ThinkPHP的
Request对象在子进程中不可达
为什么有些请求ID在日志里是空的
常见原因是中间件执行顺序错位，或者异常发生在ID注入之前。比如AppInit中间件报错退出，后续LogRequestID根本没跑；又或者Nginx转发时清掉了X-Request-ID头，而代码里又没兜底生成。
- 检查中间件定义顺序：
app/middleware.php里LogRequestID必须在AllowCrossDomain、CheckLang等前置中间件之后，但在业务中间件之前 - 在
app/exception/Handle.php的render()里加兜底逻辑：$id = $request->header('X-Request-ID', Str::uuid()) - 用
tcpdump或strace抓包确认Nginx是否透传了Header，有些配置会过滤掉带下划线的头
真正难搞的不是生成ID，是保证它在任意执行路径下都不被覆盖、不被忽略、不因异常跳过。尤其在协程或异步任务里，那个“当前请求”的边界比想象中模糊得多。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
