gin 本身不提供多数据源切换能力，因其仅是 http 路由与上下文封装框架，gin.context 不感知数据库，也不内置 orm 或连接池管理；它只负责请求流转，数据源选择、实例传递与生命周期管理须由开发者在 handler 或 service 层显式控制。
为什么 Gin 本身不提供多数据源切换能力
Gin 是 HTTP 路由与上下文封装框架，gin.Context 不感知数据库、也不内置 ORM 或连接池管理。它只负责把请求流转给 handler，剩下的——比如用哪个 *gorm.DB 实例查用户表、哪个查订单表——得你明确决定并传入。常见错误是试图在中间件里“自动切换”数据源，结果发现 c.Set("db", db1) 后，handler 里忘了 c.Get("db")，或者多个 goroutine 并发改同一个全局变量 currentDB，直接导致数据错乱。
GORM 多数据源的三种可行模式
实际项目中，推荐按场景选一种，别混用：
-
按业务模块静态绑定：用户服务固定用
userDB，订单服务固定用orderDB，启动时初始化好，handler 里直接注入或从全局变量取。适合边界清晰、读写分离明确的微服务。 -
按请求上下文动态路由：例如租户 ID 来自
c.Param("tenant_id")或 headerX-Tenant-ID，用该值查配置中心（Consul/Etcd）拿到对应数据库 DSN，再用gorm.Open()临时建连接。注意连接池复用，别每次请求都新建*gorm.DB。 -
读写分离代理层：不靠 Gin 切换，而是在 GORM 层用
gorm.Session(&gorm.Session{Context: c})+ 自定义Resolver（如func(db *gorm.DB) *gorm.DB），让SELECT走从库，INSERT/UPDATE走主库。Gin 只需透传请求，不参与决策。
在 Gin 中安全传递数据源实例的实操要点
别用全局变量存当前 DB，也别在中间件里调 c.Set("db", ...) 然后期望所有 handler 都记得 c.Get。更可靠的方式是：
- 把数据源作为依赖显式注入 handler 函数，例如
func(userRepo *UserRepository) gin.HandlerFunc，其中UserRepository内部已持有userDB； - 若必须用
c.Get，确保只在单个请求生命周期内使用，且 handler 开头就做非空校验：if db, ok := c.Get("db"); !ok { c.AbortWithStatusJSON(500, gin.H{"error": "db not found"}) }； - 避免跨中间件修改同一 key，比如日志中间件和鉴权中间件都往
c.Set("db", ...)写，顺序一变就覆盖； - 如果用了 GORM 的
Session，注意它默认不继承父会话的DB实例，要显式传：db.Session(&gorm.Session{NewDB: true}).WithContext(c)。
容易被忽略的连接泄漏点
多数据源最常崩在连接没关、池子打满。Gin 不管这个，但你得管：
- 每个
*gorm.DB实例必须调db.Close()，通常放在main()的defer或优雅关闭逻辑里； - 用
db.Session(&gorm.Session{Context: c})时，Session 本身不管理连接生命周期，它只是副本，底层还是复用原db的连接池； - 如果按租户动态开
*gorm.DB，务必限制最大租户数，并缓存已初始化的实例（map[string]*gorm.DB），而不是每次都gorm.Open()； - 检查
sql.DB.Stat()，确认OpenConnections没持续上涨，否则说明有 query 没 close 或事务没 commit/rollback。
多数据源不是 Gin 的功能开关，而是你对数据访问边界的主动划分。关键不在“怎么切”，而在“谁负责切、切完谁保管、出错谁兜底”。Gin 只提供 c 这个容器，装什么、怎么装、装多久，得你自己定规则。
