GORM 本身不支持多数据库连接池自动切换，需手动管理多个 *gorm.DB 实例并在业务中显式路由；每个实例绑定独立 sql.DB 连接池，无法跨库 JOIN，须按库初始化、命名区分、按需配置参数，并通过上下文动态选库。
直接说结论：GORM 本身没有「多数据库连接池自动切换」的内置机制，所谓“多数据库”，本质是手动管理多个 *gorm.DB 实例，并在业务逻辑中显式选择使用哪一个——不是靠配置开关，而是靠代码路由。
为什么不能只用一个 gorm.Open 连多个库？
GORM v2 的 gorm.Open 返回的是单个 *gorm.DB 实例，它底层绑定一个 sql.DB 连接池，而 sql.DB 只能指向一个数据库（MySQL/PostgreSQL 实例或 schema）。即使你在 DSN 里写 dbname=shard1 和 dbname=shard2，它们仍是两个独立连接目标，必须分别调用 gorm.Open 初始化。
常见错误现象：
- 试图复用同一个
*gorm.DB实例去执行跨库 JOIN（如SELECT * FROM shard1.users JOIN shard2.orders），会报错或返回空结果——MySQL 不允许跨实例 JOIN，PostgreSQL 需要postgres_fdw手动配置，GORM 不处理这类代理逻辑 - 把多个 DSN 拼成一个字符串传给
mysql.Open()，导致 panic：invalid DSN: missing @ or /
gorm.Open 多次调用后如何安全持有多个 DB 实例？
关键不是“能不能开”，而是“开完怎么管”。推荐在应用启动时一次性初始化所有需要的 *gorm.DB，并用包级变量或依赖注入容器持有。避免在 handler 中临时 gorm.Open，否则极易触发连接泄漏或并发竞争。
实操建议：
- 为每个数据库起明确变量名，比如
DBMaster、DBAnalytics、DBShard1，不要用db1/db2这类无意义命名 - 每个
gorm.Open必须配对defer db.Close()—— 但注意：这是指整个应用生命周期结束时关闭，不是每次请求都关；实际项目中通常不主动调用Close()，除非你确定该连接池已废弃 - 国产数据库（达梦、人大金仓）需自定义
Dialector，不能直接用mysql.Open；例如达梦驱动需实现dm.Open(dsn)并注册到gorm.Open - 连接参数（如
MaxOpenConns）应按库区分设置：分析库可设高并发连接数，日志库可限制为 5–10，避免争抢资源
请求中怎么选对 DB 实例？别依赖全局变量硬编码
最易踩的坑是：在 controller 里写死 DBShard1.First(&u)，结果上线后发现分片规则变了，或者某类请求该走从库却走了主库。动态路由必须解耦。
可行方案：
- 用 Revel 等框架的 filter 或 middleware，在请求进入时解析 URL / header / JWT claim，根据分片键（如 user_id % 4）计算出目标库，再将对应
*gorm.DB注入c.Params或 context.Value - 模型层封装
GetDB(ctx context.Context) *gorm.DB方法，内部查 context 或调用路由函数，而不是让每个Create都传参 - 禁止在 model struct 里嵌入
*gorm.DB字段——这会导致结构体实例化时意外持有连接，生命周期失控 - 测试时用
gorm.Session(&gorm.Session{NewDB: true})创建隔离 DB 实例，避免测试间污染
真正麻烦的从来不是“怎么连上”，而是“连上之后怎么让每一行 SQL 都命中正确的库”。连接初始化只是起点，上下文传递、模型适配、事务边界、日志追踪，这些环节漏掉任意一环，多数据库就变成多处故障点。
