iris 框架不内置多数据源切换能力，需开发者手动管理多个数据库客户端实例；应通过依赖注入注册命名 db 实例，避免全局变量、连接泄漏和事务跨源问题。
iris 框架本身不内置多数据源切换能力
「Iris」是 Go 语言的 Web 框架（github.com/kataras/iris/v12），它专注 HTTP 路由、中间件、MVC 和模板渲染，**不提供数据库连接池管理或数据源抽象层**。所谓“多数据源切换”，实际是开发者在业务逻辑中手动管理多个数据库客户端实例，并按需调用——框架只负责把请求路由到对应 handler，剩下的全得自己兜底。
如何在 iris 中安全持有并切换多个数据库连接
核心思路：把不同数据源的 client（如 *sql.DB 或 ORM 实例）注册为依赖，通过 context 或 handler 参数传入，避免全局变量和竞态风险。
- 用
app.ConfigureContainer注册多个命名的*sql.DB实例（例如"primary"、"analytics"），配合第三方容器如github.com/uber-go/dig或 iris 自带的简易依赖注入（app.RegisterValue） - 不要在 handler 中直接
sql.Open—— 连接应提前初始化、校验、设置SetMaxOpenConns/SetMaxIdleConns，并在应用启动时统一 panic 捕获失败 - 切换逻辑写在具体 handler 内，比如根据 URL path 或 query 参数决定用哪个库：
if c.URLParam("db") == "analytics" { useDB = analyticsDB } else { useDB = primaryDB } - 若用 GORM，注意每个
*gorm.DB实例默认绑定一个*sql.DB；多个数据源需创建多个独立的*gorm.DB，不能共用同一个*sql.DB
常见踩坑点：事务跨数据源、连接泄漏、配置硬编码
多数据源最易被忽略的是事务边界和生命周期管理：
-
sql.Tx只能作用于单个*sql.DB，无法跨数据源开启分布式事务 —— 若业务强依赖跨库一致性，必须改用最终一致性方案（如消息队列 + 补偿） - 忘记调用
db.Close()或未设置SetConnMaxLifetime，导致连接堆积、数据库拒绝新连接（错误如"dial tcp: lookup xxx: no such host"或"too many connections"） - 把数据库地址/密码写死在代码里，或从环境变量读取但没做空值校验，导致服务启动成功但首次查询就 panic
- 用
iris.Context的Values().Set存储 DB 实例 —— 这个 map 不是线程安全的，且生命周期与请求绑定，不适合存长连接对象
替代建议：用 AnyLine 或自建 DataSourceManager
如果你真需要运行时动态增删数据源、自动适配 SQL 方言、支持异构库（如 IRIS + MySQL + PostgreSQL），Iris 就不是合适载体。这类需求更适合：
- 在 service 层引入
AnyLine这类元数据驱动型库，它能根据表名/租户 ID 动态路由到对应数据源，并生成兼容方言的 SQL；iris 只做 API 入口，把AnyLine.DataSourceManager当作单例注入即可 - 自己封装一个
DataSourceManager结构体，内部用sync.Map缓存map[string]*sql.DB，提供Get(name string) (*sql.DB, error)方法，配合配置热更新（如监听 etcd/ZooKeeper 变更） - 避免在 Iris 的
mvc.Application中尝试“自动注入 DB”——它的依赖注入仅限 controller 初始化阶段，无法响应运行时数据源变更
真正麻烦的从来不是“怎么切”，而是“切完之后事务怎么收口、连接怎么回收、错误怎么归因”。这些细节不提前设计，上线后只会靠日志一行行扒 goroutine stack。
