context::set()和context::get()在子协程中拿不到值，是因为协程上下文默认不继承，每个新协程有独立cid，父协程设置的数据仅绑定于自身cid；正确做法是显式调用context::copy()复制上下文，或使用hyperf\coroutine\parallel自动继承。
Context::set() 和 Context::get() 为什么在子协程里拿不到值
不是方法写错了，是协程上下文默认不继承。每个 Coroutine::create() 或 go() 启动的新协程都有独立 CID，Context::set('user_id', 123) 只写入当前 CID 的存储空间，子协程查不到。
常见错误现象：
- 父协程设了
Context::set('trace_id', 'abc')，子协程Context::get('trace_id')返回null - 中间件里存了用户信息，控制器里却读不到——因为中间件和控制器可能不在同一个协程里（比如用了
go()）
正确做法：
- 简单场景：用
Context::copy()显式复制上下文：go(function () use ($ctx) { Context::set('trace_id', $ctx['trace_id'] ?? null); }, Context::all()); - 推荐封装：改用
Hyperf\Coroutine\Parallel，它会自动继承父协程上下文，避免手动传参出错 - 异步任务启动前，必须先取再 set：
$traceId = Context::get('trace_id'); go(fn() => Context::set('trace_id', $traceId));
RequestInterface 和 Context::get(ServerRequestInterface::class) 怎么选
控制器方法参数里声明 RequestInterface $request 是最安全、最推荐的方式；工具函数或非控制器类里想取请求参数，不能依赖 $_GET，但也不能无脑用 Context::get(ServerRequestInterface::class)。
原因：
-
$_GET在 Hyperf 里根本不可靠——Swoole 协程运行时不注入全局变量，多个请求共用同一块内存，$_GET是上一个协程留下的脏值 -
Context::get(ServerRequestInterface::class)虽然能拿到，但前提是该对象已由框架写入上下文（比如中间件或内核层），不是所有场景都保证存在 - 直接从
$request参数取值，类型明确、IDE 可提示、自动校验，且生命周期与当前请求严格对齐
实操建议：
- 控制器/中间件内：优先用
$request->get('id')或$request->input('name') - 服务类、工具类中需要请求上下文：通过构造函数注入
RequestInterface，或显式从上下文中取：Context::get(ServerRequestInterface::class)?->get('id')（注意空判断） - 绝对不要在任何地方写
global $_GET或$_POST
static 属性和 $this->xxx 为什么导致用户数据串流
因为 static 是进程级的，而 $this->xxx 依赖的是单例服务实例——Hyperf 默认把 UserService 这类服务注册为单例，整个 Worker 进程只初始化一次，所有协程共享同一个对象。
后果很直接：
- A 用户登录后执行
$this->user_id = 1001，B 用户请求进来立刻读到1001 - 订单、权限、日志全错乱，问题只在高并发时复现，本地单测永远测不出
替代方案：
- 用 DI 容器每次获取新实例：
ApplicationContext::getContainer()->get(UserService::class)（需配置为非单例） - 轻量状态走 Context：
Context::set('user_id', 123)+Context::get('user_id')，记得在关键路径（如中间件）里 set，在 try/catch 后 destroy 防残留 - 如果必须用属性存状态，确保服务类是 prototype 作用域（
@Scope(ScopeInterface::PROTOTYPE)）
父子协程嵌套深了，Context 怎么不丢又不爆内存
多层 go() 或 co() 嵌套时，手动 copy 上下文容易漏、易重复、难维护；但全靠 Context::copy() 又可能把整块上下文（含大对象）反复拷贝，引发内存压力。
更稳妥的做法是“锚定根协程”：
- 定义一个
getRootCid(): int函数，递归调用Coroutine::getPcid()直到找到最顶层 CID - 所有关键数据统一写进根协程上下文：
Context::set(getRootCid(), 'user_id', 123) - 任意子协程都可通过
Context::get(getRootCid(), 'user_id')读取，无需传递、不占额外内存 - RPC 场景直接用
RpcContext::set()/RpcContext::get()，它底层就是按根 CID 存的，中间件自动透传
特别注意：Context::set() 没有自动清理机制，异常跳出时若没 destroy()，下次复用同 CID 会读到上一次的残留值——这是最隐蔽也最常被忽略的一环。
