Gin 多数据库需手动管理连接池与映射，每个数据源必须独立调用 sql.Open() 或 gorm.Open() 并存入 sync.Map；handler 中显式取 alias 查 map 获取 DB，goroutine 需显式传参，事务不可跨库，租户配置变更须重建实例。
Gin 本身不提供多数据库源切换能力，所谓“配置”其实是你手动组织连接池、缓存映射和上下文传递的整套流程；硬套 Spring 的 AbstractRoutingDataSource 思路会直接失败——Go 没有线程绑定上下文，也没有运行时 Bean 注入机制。
怎么初始化多个 DB 实例并安全复用
每个数据源必须独立调用 sql.Open() 或 gorm.Open()，不能共用一个 *sql.DB 变量去“切换 DSN”。否则事务错乱、连接泄漏、panic 都是常态。
- 启动阶段读 YAML/INI 配置（如
config.yaml中的db_list数组），按alias字段逐个建连 - 每个实例单独设置连接池：
db.SetMaxOpenConns(30)、db.SetMaxIdleConns(10)、db.SetConnMaxLifetime(60 * time.Second) - 存进全局
map[string]*sql.DB或sync.Map，key 为 alias（如"user-master"），禁止在 handler 里重复调sql.Open() - 别在
init()函数里初始化 DB：错误无法透出，服务启动失败难定位；改用显式工厂函数，如NewUserDB(cfg)
如何在 handler 中显式选择指定 DB
Gin 的 Context 不保存 DB 实例，也没有自动注入机制。所谓“动态选库”，本质是显式取值 + 显式传参。
- 最简方式：
db := global.MustGetGlobalDBByDBName("log")，硬编码 alias，适合固定场景 - 路径驱动方式：URL 设计为
/api/v1/:db_alias/users，handler 中用c.Param("db_alias")提取后查 map - 中间件注入方式：从
X-Tenant-ID或 JWT 中提取标识，查sync.Map获取 DB 实例，再塞进context.WithValue() - 务必检查类型断言是否成功：
if db, ok := ctx.Value(tenantDBKey).(*sql.DB); !ok { /* 返回 500 或 fallback */ }，否则 panic
goroutine 中访问 DB 容易踩的坑
Go 的 goroutine 不继承父 goroutine 的 context 值，也不能靠 “上下文透传” 自动带过去。任何异步任务都必须显式把 DB 实例或 alias 作为参数传入。
- 错误写法：
go func() { db := global.GetDBFromCtx(c.Request.Context()) }()——c.Request.Context()在新 goroutine 里不会生效 - 正确写法：
go doAsyncJob(global.MustGetGlobalDBByDBName("log"))或go doAsyncJob("log")（内部再查 map） - 如果用了类似 Spring @Async 的封装，立刻停手——Go 没有这种运行时代理能力
- 事务内操作必须严格限定在同一个
*sql.DB实例上；跨库调用（比如主库写 + 日志库写）不属于事务范围，不会回滚
sync.Map 缓存租户 DB 时的关键细节
用 sync.Map 缓存 tenant_id → *sql.DB 映射是常见做法，但它的 API 返回 value, loaded bool，直接类型断言极易 panic。
-
db, loaded := tenantDBs.Load(tenantID)后，必须判断loaded，再做db.(*sql.DB) - 首次加载建议用
LoadOrStore，避免并发重复初始化；但注意它返回的是interface{}，仍需类型断言 - 租户配置变更（如 DB 地址更新）时，不能热替换底层连接；必须
LoadAndDelete+ 重建新实例，再Store - 别把
sync.Map当万能解药——小规模租户（map +sync.RWMutex更清晰、更易测试
最常被忽略的一点：所有 DB 切换逻辑都发生在业务代码层，Gin 仅负责路由和上下文封装；一旦混淆“框架能力”和“你写的调度逻辑”，问题就会从配置错误演变成运行时不可控的连接耗尽或事务丢失。
