不能直接用全局变量或静态属性存请求数据，因为hyperf协程下多请求共享内存，会导致数据覆盖和错乱；必须使用context::set()/get()在中间件中写入、controller中读取，确保协程隔离。
为什么不能直接用全局变量或静态属性存请求数据
Hyperf 默认开启协程，同一个 PHP 进程里多个请求共享同一份内存空间。如果在控制器或服务里直接写 $this->user_id = 123 或 self::$current_user_id = 123，下个协程一执行就可能把值覆盖掉——你拿到的可能是别人请求的数据。
典型现象：A 用户登录后访问订单页，返回了 B 用户的订单；日志里看到 User ID: 456 却出现在 A 的请求 trace 中。
根本原因不是“变量没清空”，而是协程之间根本没有隔离——必须靠 Context 显式划清边界。
Context::set() 和 Context::get() 的正确调用时机
Context 只在当前协程生命周期内有效，且不会自动跨协程传递（比如 go() 启的新协程需手动传递）。最安全的写法是在中间件里注入请求级变量，并在 Controller 层只读取。
- 在
App\Middleware\JwtAuthMiddleware中解析完 token 后立即调用Context::set('user_id', $uid) - Controller 方法里用
Context::get('user_id')，不要在构造函数里取——构造函数运行时 Context 还未被中间件填充 - 避免在
go(function () { ... })里直接读 Context，应显式传参：go(function () use ($uid) { ... })
Context 与 DI 容器作用域的区别
有人会想：我注册一个 Singleton 并设置为 RequestScoped 不就行了？不行。Hyperf 的 RequestScoped 是基于 HTTP 生命周期模拟的，底层仍是协程共享对象；而 Context 是 Swoole 原生支持的协程局部存储，由协程 ID 自动索引，更底层、更可靠。
对比：
-
Context::get('user_id')→ 返回当前协程绑定的值，100% 隔离 -
Container::get(UserContext::class)->getUserId()→ 如果这个类是Singleton，所有协程共用一个实例，必然污染 -
Container::get(UserContext::class)设为RequestScoped→ 理论上可行，但实际中容易因依赖注入链过长或异步调用丢失 scope
Context 在异常和 defer 场景下的存活表现
Context 数据会在协程结束时自动销毁，但要注意两个例外：
- 协程抛出未捕获异常时，Context 仍有效，可用于异常中间件记录上下文信息（如
Context::get('request_id')） - 使用
defer()注册回调时，回调运行在原协程结束前，Context 可正常读取；但如果 defer 里又go()了一个新协程，那新协程里 Context 是空的 - 切勿在
onWorkerStart或定时任务@Crontab里依赖 Context，这些场景压根不在 HTTP 请求协程中
最稳妥的做法：所有 Context 写入动作都限定在中间件或前置钩子里，所有读取动作都加默认值和类型断言，比如 Context::get('user_id', 0)，避免 null 导致后续逻辑崩掉。
