Hyperf 3.1 数据库连接隔离靠协程连接池+Context状态隔离，非手动存取Connection；Context不存PDO/Connection对象，只存tenant.id等元数据；事务必须用DB::transaction()且禁止跨协程调用。
Hyperf 3.1 中，协程间用 Context 隔离数据库连接，核心不是“手动存取连接”，而是**依赖框架自动绑定 + 禁止跨协程复用连接对象**。Context 本身不直接管理数据库连接，它保障的是“连接归属关系不被污染”，而真正的隔离由协程连接池和 DB::transaction() 的封装逻辑共同完成。
Context 不是数据库连接的容器，而是状态隔离的载体
你不能也不该把 PDO 实例或 Connection 对象塞进 Context::set()。原因很直接：
- Connection 对象内部持有底层协程 MySQL 连接资源，该资源已按协程 ID 绑定到当前上下文，无法安全转移
- Context::set('db_conn', $conn) 后，若在另一协程中 get 到这个 $conn，调用 query() 会实际使用新协程的连接（因为 $conn->query() 内部会重新从连接池拿连接），造成行为不可控
- 静态变量、全局变量、单例类里缓存连接，才是串连的根源；Context 的作用是帮你绕开这些错误模式
真正起隔离作用的是连接池 + 协程上下文绑定
Hyperf 数据库连接池在底层通过 Swoole/Swow 的协程机制，为每个协程分配专属连接，并用 Context::set() 将连接句柄隐式绑定到当前协程 ID。你不需要手动操作这层绑定，但必须遵守它的约束：
- 所有数据库操作（包括查询、事务）必须在同一个协程内完成
- 务必使用 DB::transaction() 而非 beginTransaction()/commit() 手动控制——前者自动完成“获取连接 → 开启事务 → 执行 → 提交/回滚 → 归还”闭环
- 在 CLI 命令中启用协程环境（Swoole\Runtime::enableCoroutine(true)）后，再调用 DB::transaction()，连接自然属于当前 CLI 协程
需要 Context 显式介入的典型场景
虽然连接本身不由 Context 管理，但以下情况需用 Context 存储与连接强相关的**元数据**，确保逻辑一致性：
- 租户标识：多租户系统中，在中间件里解析 tenant_id 后，Context::set('tenant.id', $id)，后续 DAO 层根据此值动态切换数据库名或前缀
- 读写分离标记：Context::set('db.force_write', true) 控制某次请求强制走主库，避免从库延迟导致的数据不一致
- 调试追踪 ID：Context::set('trace.id', uniqid())，让日志、慢查、SQL 监控能关联到同一请求链路
错误示范与后果
这些做法会导致连接错乱或事务失效：
- 在协程 A 中执行 DB::transaction()，闭包内用 go() 启动协程 B 并在其中调用 DB::table()->insert() → B 使用自己的连接，不在事务中
- 定义 static $connection，在构造函数里赋值 $this->connection = DB::connection() → 多个协程共享该静态引用，查出其他用户的数据
- 用 Context::set('conn', DB::connection())，然后在子协程中 get 出来调用 beginTransaction() → 实际开启的是子协程的连接，父协程事务已丢失
