Hyperf控制器数据混淆主因是误用$this->xxx或static存请求级数据，因Controller默认单例且协程不隔离对象属性；应改用Context::set()，并注意子协程需显式Context::copy()传递上下文。
Hyperf控制器里出现数据混淆，基本可以断定是用了 $this->xxx 或 static $xxx 存请求级数据——协程不隔离对象属性和静态变量，必须立刻改用 Context::set()。
为什么控制器成员变量会串数据
Hyperf 的 Controller 默认是单例，整个 Worker 进程只初始化一次实例。多个协程（即多个请求）共用同一个 Controller 对象，$this->user_id、$this->cache、$this->requestId 这类成员变量写进去后不会自动清空，下一个协程进来直接读到上一个请求的值。
常见现象包括：
- 接口返回了其他用户的订单列表
- 缓存 key 拼接出错，查到的是前一个请求的数据
- 日志里
user_id=123和user_id=456的请求混在同一条 trace 中
这不是 bug，是 PHP 协程模型 + Hyperf 单例设计的必然结果。
怎么快速定位哪个成员变量在作祟
在控制器方法入口加一段检查逻辑，把所有非 null 的 protected/private 成员变量打出来：
public function index()
{
$ref = new \ReflectionObject($this);
foreach ($ref->getProperties(\ReflectionProperty::IS_PROTECTED | \ReflectionProperty::IS_PRIVATE) as $prop) {
$prop->setAccessible(true);
$val = $prop->getValue($this);
if ($val !== null && !is_object($val)) {
\Hyperf\Logger\LoggerFactory::get('debug')->info('controller prop leak', [
'prop' => $prop->getName(),
'val' => $val,
'coroutine_id' => \Hyperf\Coroutine\Coroutine::id(),
]);
}
}
// ...
}
重点盯这些字段：
-
$this->user、$this->authData—— 鉴权信息最常被污染 -
$this->cache、$this->data—— 缓存数组追加不清理，越积越大 -
$this->errors—— 表单验证错误反复[]=，最后返回空数组或混合错误
Context::set() 用错也会失效
Context::set() 不是万能胶，用错场景照样串：
- 在
go(function () { Context::get('xxx'); })里取不到值 → 子协程默认不继承父上下文，要显式Context::copy() - 在中间件里
Context::set('user', $user)，但 DAO 层用$request->getAttribute('user')→ 后者只在当前ServerRequest对象有效，不穿透到底层 DB/Redis 调用 - 用
Context::set('db_conn', $conn)但没配合事务生命周期管理 → 协程结束时连接未释放，下次复用可能连错库
正确姿势是：所有下游异步调用（DB 查询、Redis 写入、HTTP 客户端）都统一从 Context::get() 取值，不要依赖 $this 或 $request。
排查时别漏掉 runtime/logs/swoole.log
有些数据混淆不是代码逻辑问题，而是底层崩溃导致上下文损坏。比如：
- MySQL 连接异常断开后，协程上下文残留脏状态，后续 Redis 操作直接复用错误上下文
- Swoole 报
coroutine is dead或Segmentation fault，之后的请求上下文就不可信
执行 tail -f runtime/logs/swoole.log，复现问题时观察是否有这类关键词。如果存在，先解决崩溃根源，再回来看业务逻辑。
真正难缠的混淆往往藏在「协程上下文被意外覆盖」和「单例对象生命周期远超请求」的交界处——那里没有报错，只有静默的数据错位。
