Hyperf 中切换多数据库连接的关键是避免协程污染、连接未释放和池配置不当；需为每个库设独立命名与完整池参数，显式指定连接名操作，事务绑定具体连接，合理控制协程内切换频次并确保连接及时归还。
在 Hyperf 中循环遍历切换多个数据库连接，关键不是“能不能切”，而是“怎么切不踩坑”。最常报错的根源是协程上下文污染、连接未释放、或连接池配置不合理，而非切换动作本身。
确保每个连接有独立语义名和完整池配置
不要共用连接池，哪怕都是 MySQL。不同库（尤其是版本、部署方式不同）必须单独定义连接项，并显式配置 pool 参数：
- 连接名要有业务含义，比如
log_db、report_pg、tenant_001，避免用db1、db2 - 每个连接下
pool必须完整声明：min_connections、max_connections按实际数据库承载力设（如 MySQL 5.7 实例 max_connections=200，对应池 max_connections ≤ 150） - 跨大版本（如 MySQL 5.7 vs 8.0）需补认证参数：
'options' => [PDO::ATTR_EMULATE_PREPARES => true]或PDO::MYSQL_ATTR_SSL_MODE => PDO::SSL_NONE
循环中用 connection() 显式指定，别依赖默认
不要在循环里反复调用 Db::connection() 后再链式操作——它返回的是连接实例，但若没及时释放或上下文残留，容易串连。推荐写法：
- 每次操作都带连接名：
Db::connection('log_db')->table('logs')->where(...)->get() - 事务必须绑定具体连接：
Db::connection('report_pg')->transaction(function () { ... }) - 避免在循环内嵌套事务，尤其跨库事务——Hyperf 不支持分布式事务，强行做会锁表或报错
注意协程上下文与连接复用边界
Hyperf 的 Db::connection($name) 默认从协程上下文取已建立的连接。如果循环中混用多个连接，又没清空上下文，旧连接可能被误复用：
- 不建议在单个协程内高频切换大量连接（如 100+ 次），应按业务聚合查询，减少切换频次
- 若需严格隔离，可在每次操作前手动清理上下文键：
Context::set(Db::getContextKey('log_db'), null)（慎用，仅调试时排查用） - 更稳妥的方式：把不同库的操作拆到独立协程中，用
Coroutine::create()并显式透传连接名和参数
检查连接是否真正释放
常见报错 Too many connections 或 No available connection 往往不是切多了，而是没放回去：
- 确认没有在循环中漏掉
finally块或异常分支导致连接未归还 - 避免在连接上调用阻塞操作（如
sleep()、同步 HTTP 请求），这会让连接长时间占用 - 用
hyperf:monitor查看各连接池实时状态：connections_used和connections_idle是否平衡
