Gin实现多数据源需手动初始化多个DB实例并存入全局map，通过alias显式获取，无自动路由机制；读写分离须业务层硬编码选择master/slave实例，goroutine中需显式传入DB而非依赖上下文透传。
Gin 本身不提供多数据源管理能力，必须靠你自己组织数据库连接池、切换逻辑和上下文传递机制。硬套 Spring 那套 AbstractRoutingDataSource 路由思路在 Go 里行不通——没有线程绑定上下文、没有自动代理、也没有运行时 Bean 注入。
怎么让 Gin 启动时加载多个 DB 实例
别试图在 gin.Engine 上挂 DB，那是 HTTP 路由器，不是数据源容器。正确做法是：启动阶段读配置 → 按 alias 初始化多个 *gorm.DB 或 *sql.DB 实例 → 存进全局 map 或结构体中供业务调用。
- 配置建议用 YAML 或 INI，比如
config.yaml里写db-list数组，每个元素带alias-name、type、username等字段 - 初始化时用
gorm.Open()或sql.Open()分别建连，注意设置SetMaxOpenConns和SetMaxIdleConns - 存进
map[string]*gorm.DB时 key 用alias-name，后续通过global.GetGlobalDBByDBName("test1")获取 - 避免在 handler 里直接调
sql.Open()—— 连接池要复用，不能每次请求都新建
如何在 handler 中动态选库
没有“自动路由”，只有“显式选择”。Gin 的 Context 不保存 DB 实例，你得自己把 DB 传进去或从全局取。
- 最简方式：handler 里硬编码
db := global.MustGetGlobalDBByDBName("business-master") - 想解耦？把 DB alias 当参数传进来，比如 URL path 中带
/api/v1/:db_alias/users，然后用c.Param("db_alias")拿到再查 map - 别依赖中间件“注入 DB”——中间件无法修改 handler 签名，也不能给每个 handler 塞不同 DB 实例
- 如果用了 GORM，注意
*gorm.DB是非线程安全的，但它的底层*sql.DB是安全的；所以只要不共享*gorm.DB实例（比如全局单例），而是每个 alias 对应一个独立*gorm.DB，就 OK
异步任务里访问指定数据源容易踩什么坑
Go 的 goroutine 没有继承主线程的上下文，goroutine 里调用 global.GetGlobalDBByDBName() 没问题，但如果你试图把 DB 切换逻辑（比如基于 tenant ID）塞进 goroutine，就会丢失上下文。
- 错误示范：主线程设了
ctx.Value("db_key") = "log"，然后go func() { db := getDBFromCtx(ctx) }—— 这个ctx在 goroutine 里不会自动生效 - 正确做法：把需要的 DB alias 或已打开的
*gorm.DB实例作为参数显式传进 goroutine，例如go doAsyncJob(global.MustGetGlobalDBByDBName("log")) - 如果用了
@Async那套思维，立刻停手——Go 没有 Spring 那种 AOP 织入和上下文透传机制，强行模仿只会让代码不可测、难调试
读写分离怎么配才不翻车
别指望 Gin 自动识别 SELECT 还是 INSERT。所谓“读写分离”，本质是业务层决定用哪个 DB 实例。
- 可以定义两个 alias：
business-master和business-slave，分别对应主库和从库 - 写操作固定用 master：
global.MustGetGlobalDBByDBName("business-master").Create(&u) - 读操作按需选 slave：
global.MustGetGlobalDBByDBName("business-slave").First(&u, id) - 不要尝试在 SQL 解析层做路由——Go 生态几乎没有成熟可靠的 SQL 解析+重路由库，且性能损耗大、兼容性差
- 如果 slave 延迟敏感，加个健康检查或超时 fallback 到 master，而不是静默失败
真正麻烦的从来不是“怎么连多个库”，而是“怎么让业务代码清晰知道该用哪个库、什么时候该切、出错了往哪查”。Gin 只管 HTTP，DB 路由得你亲手焊死在业务逻辑里。
