hyperf中静态变量导致连接混淆，因其在进程内全局共享，而多个协程共用同一worker进程，a请求写入的static变量（如$conn、$user_id）未清理，b请求直接读取造成数据串流；context::set通过coroutine::getcontextfor($coroutineid)将数据绑定至当前协程id实现隔离，协程结束自动释放，新协程拥有独立上下文。
Hyperf里静态变量为什么会导致连接混淆
因为静态变量在进程内全局共享，而Hyperf运行在Swoole协程环境里——多个请求共用同一个Worker进程，但每个请求跑在独立协程中。一旦你在类里用static $conn或static $user_id存数据，A请求写入后还没清理，B请求进来直接读到A的值，连接、用户身份、事务状态全串了。
常见现象包括：
-
MySQL连接被复用错库，查出其他用户的订单 - Redis客户端写入
set('token', 'abc')后，下一个协程get('token')拿到的却是上一个请求的值 - 中间件里
static $authData被覆盖，导致鉴权失败或越权访问
Context::set/get 是怎么隔离协程数据的
Context不是简单地用数组存值，它底层调用的是Coroutine::getContextFor($coroutineId)，把数据绑定到当前协程ID对应的上下文容器里。协程结束时，这块内存自动释放；新协程启动时，自带干净的空上下文。
关键点：
-
Context::set('db_conn', $conn)只影响当前协程，子协程不会继承（除非显式Context::copy()） - 非协程环境（如命令行脚本、测试用例）下，
Context会退化为静态数组，行为一致但不跨进程 - 不要和
RequestInterface::getAttribute()混用：后者只对当前ServerRequest对象有效，不穿透到DB/Redis等异步调用中
哪些地方必须用Context而不是类属性或静态变量
凡是跟单次请求强绑定、且可能被下游异步操作（比如go、Co::create、HTTP客户端、数据库查询）访问的数据，都得进Context。
典型场景：
- 链路追踪ID：
Context::set('trace_id', $request->getHeaderLine('X-Trace-ID')) - 当前登录用户：
Context::set('current_user', $user)，后续DAO层可直接取，不用层层传参 - 事务上下文：
Context::set('db_transaction', $pdo->beginTransaction())，确保同一请求所有DB操作走同一个事务 - 临时缓存键前缀：
Context::set('cache_prefix', 'req_'.uniqid())，避免并发写冲突
Context跨协程传递TraceId失败怎么办
这是最常踩的坑：Context::set()设完，进go(function () { Context::get('trace_id'); })就返回null。根本原因不是Context失效，而是新协程没继承原上下文。
正确做法只有两种：
- 用
Co::create()并传入上下文快照：Co::create($callback, Context::copy()) - 手动在
go闭包里重置：go(function () use ($context) { Context::set($context); /* 后续逻辑 */ });
注意：Context::copy()必须在go之前调用，且$context变量本身不会自动生效——它只是个数组快照，你得主动Context::set($context)才真正挂载。
复杂点在于，Hyperf封装的HttpClient、Db、Redis等组件内部可能隐式创建新协程（比如连接池切换、重试），它们不会自动透传Context。这时候得靠中间件+装饰器+自定义客户端配合，不能只靠一次set就万事大吉。
