hyperf 3.0 中闭包监听模型事件会导致协程上下文丢失，无法获取用户id、traceid等数据；应改用类监听器并显式注入上下文，或在中间件中预设context值确保一致性。
Hyperf 3.0 中模型事件（如 creating、saving）配合闭包监听器时，协程上下文丢失是高频问题——不是事件没触发，而是闭包里取不到当前请求的 Context 数据（如用户 ID、TraceID），导致日志断链、权限错乱或缓存污染。
闭包监听器天然不继承协程上下文
Hyperf 的模型事件监听器若用闭包注册（例如在 boot() 中调用 Event::listen(…, function () { … })），该闭包运行时处于新协程环境，且未自动绑定父协程的 Context。它无法访问 Context::get('user_id') 或 RequestInterface::getAttribute() 等依赖当前请求上下文的数据。
- 闭包由事件分发器直接调用，不经过容器管理，也不走协程上下文拷贝逻辑
- 即使你在主协程中
Context::set('trace_id', 'xxx')，闭包里Context::get('trace_id')仍返回null - 这不是 Bug，是设计使然：闭包监听器无生命周期托管，Context 隔离机制默认不介入
改用类监听器 + 显式注入上下文
推荐方案是弃用闭包监听，改用标准类监听器，并在 process() 方法中通过容器解析或手动传入上下文关键值。
- 新建监听器类（如
App\Listener\ModelSavingListener），实现ListenerInterface - 在
process()中用Context::get('current_user')安全读取（前提是主流程已写入） - 若需跨协程传递（如模型保存触发异步任务），应在触发前显式
Context::copy()并传给子协程 - 避免在
process()中直接调用go(function () { Context::get(...) })—— 子协程默认不继承上下文
模型事件中安全读取上下文的实操建议
模型层本身不感知协程上下文，所以不能依赖 $this->request 或静态属性。正确做法是：在业务入口（如 Controller）或中间件中，将必要上下文数据提前写入 Context，并确保模型操作发生在同一协程内。
- 中间件中写入：
Context::set('current_user', $user)，后续所有模型事件监听器均可读取 - 避免在监听器中重新查询用户（如
User::find()），防止因事务或连接池复用引发一致性问题 - 若监听器需发起 HTTP 请求或 DB 查询，确保使用协程客户端（
Hyperf\HttpClient\Client、DB::transaction()） - 调试时可用
Co::getUid()辅助验证是否仍在同一协程：主协程和监听器中应返回相同 UID
临时兜底：闭包内手动捕获上下文快照
若必须用闭包监听（如快速原型），可在注册前捕获当前上下文快照，再闭包内引用：
$traceId = Context::get('trace_id') ?: uniqid('trc_');Event::listen(ModelSaving::class, function ($event) use ($traceId) {- 注意：这只适用于只读上下文，且不能动态更新；不适用于需实时鉴权或事务关联的场景
