hyperf 3.1 的常驻内存机制导致 static $instance 跨请求污染，因 worker 进程长期存活且协程共享静态变量内存；安全方案包括协程 uid 隔离缓存或 di 容器设置 shared=false。
Hyperf 3.1 的常驻内存机制让服务启动后 Worker 进程长期存活，静态变量、单例对象、全局缓存不再随请求销毁——这带来性能飞跃，也埋下数据污染、内存泄漏、协程错乱三重风险；不理解其运行边界就直接复用 PHP-FPM 时代的写法，接口一并发就返回错乱结果。
为什么 static $instance 在 Hyperf 里会跨请求污染
第一步：打开 Swoole Worker 进程生命周期图——它启动后持续运行，不重启就不会释放内存。
第二步：观察类中定义的 【static $instance = null】，这个变量绑定在进程地址空间，所有协程共享同一块内存地址。
第三步：协程 A 执行 Database::getInstance()->setUser(1001)，把用户 ID 写进 $instance；协程 B 紧接着调用 getInstance()，拿到的是已被 A 修改过的实例，【不是新对象，而是被篡改的旧对象】。
第四步：这种污染无法通过 reload 或平滑重启清除，必须 kill -USR1 重启 Worker 才能重置。
协程本地单例的两种安全写法
方法一：用 Swoole\Coroutine::getUid() 构建隔离键
在 getInstance() 中生成键名 $key = 'db_' . Swoole\Coroutine::getUid()；用 SplArray 或数组缓存该协程专属实例；每次获取都检查 $key 是否存在，不存在则 new 并存入。注意：缓存容器本身不能是 static 变量，否则又回到进程级共享陷阱。
方法二：依赖注入容器显式控制生命周期
在 Hyperf 容器配置中为 DB 类声明 【shared=false】，例如 @Inject注解加参数 shared=false，或调用 make(DbConnection::class, [], true)；这样每次 make 都返回新实例，天然协程隔离。验证方式：两个并发协程打印 $container->get(DbConnection::class)->getUid()，ID 不同即生效。
高频踩坑场景与即时修复动作
场景1：日志单例缓存 trace_id 导致多请求日志混写
立刻将 Logger 实例从 static 属性移出，改用上下文传递：在中间件中生成 trace_id → 注入到 Request 对象 → Controller 中通过 $request->getAttribute('trace_id') 获取，不再依赖任何全局状态。
场景2：Redis 连接复用导致事务串连
禁止在构造函数中直接 $this->redis = RedisFactory::getInstance()；改为每次操作前调用 $this->redisPool->get() 获取连接，用完 $this->redisPool->put($conn)，由连接池管理生命周期和协程绑定。
场景3：自定义全局计数器在压测中数值翻倍
把 count++ 这类操作全部替换为 Co\Channel 操作：初始化时 $chan = new Co\Channel(1) → push(0)；每次计数前 pop() → +1 → push() 回去；Channel 天然绑定当前协程，无需锁，无竞争。
