*gorm.DB 实例不支持运行时切库，因底层 *sql.DB 在 gorm.Open 时已绑定 DSN 和驱动配置；正确做法是为每个数据源单独调用 gorm.Open 创建独立实例，并分别配置连接池、时区等参数。
gorm.Open 生成的 *gorm.DB 不支持运行时切库
很多人以为改个 DSN 或重设连接参数就能让一个 *gorm.DB 实例切换到另一个数据库，实际完全无效。GORM 的 *gorm.DB 是不可变封装，底层 *sql.DB 在 gorm.Open 时就绑死了 DSN 和驱动配置。强行修改会导致 panic 或静默失败。
正确做法是：每个数据源必须调用一次 gorm.Open，生成独立的 *gorm.DB 实例。比如主库、日志库、统计库，要分别有 primaryDB、logDB、statDB 三个变量。
- 别把多个
*gorm.DB存进同一个全局变量（如var DB *gorm.DB），容易误用 - 推荐用结构体字段或 map 区分：
type DBs struct { Primary *gorm.DB; Log *gorm.DB } -
AutoMigrate、事务、预加载都只在单个实例内生效，跨实例调用等于没走事务
Transaction 方法无法跨数据源生效
db.Transaction(func(tx *gorm.DB) error { ... }) 只绑定当前 *gorm.DB 对应的 *sql.Tx。如果你在事务函数里混用 primaryDB 和 logDB，logDB.Create() 根本不参与事务，提交/回滚都影响不到它。
常见错误写法：
primaryDB.Transaction(func(tx *gorm.DB) error {
tx.Create(&user)
logDB.Create(&action) // 这行完全游离于事务外！
return nil
})
真正能保证一致性的方案只有两种：
- 上分布式事务中间件（如 Seata），但 Go 生态成熟度低、运维成本高
- 退化为“尽力而为”：先同步写主库，再异步发消息触发日志库写入；失败靠补偿任务修复（比如定时扫描未完成日志，重试或告警）
跨库关联查询只能手写 Raw 或内存合并
GORM 的 Preload 和 Joins 都要求所有表在同一个数据库内。如果用户信息在 primaryDB，操作日志在 logDB，就无法用 user.Preload("Actions") 一次性查出。
可行替代方式：
- 用
primaryDB.Raw("SELECT * FROM users WHERE id IN ?").Scan(&users)+logDB.Where("user_id IN ?", ids).Find(&actions)，然后在内存里按 user_id 合并 - 若数据量大、延迟敏感，考虑冗余字段（如日志表里存 user_name 而非只存 user_id）
- 避免在 HTTP 请求中做多次 DB 查询拼接，应提前评估 N+1 问题，必要时用 goroutine 并发 fetch
连接池和时区参数必须每个 DSN 单独配
loc=Local、parseTime=true、charset=utf8mb4 这些不是 GORM 层的配置，而是 MySQL 驱动解析 DSN 时的行为。不同库可能部署在不同时区机器上，或要求不同字符集，共用一套 DSN 模板会出错。
连接池也一样：primaryDB.Session(&gorm.Session{}).DB().SetMaxOpenConns(50) 和 logDB.Session(&gorm.Session{}).DB().SetMaxOpenConns(10) 必须分开调，否则高流量日志写入可能耗尽主库连接数。
容易被忽略的一点是：测试时往往只连单库，事务和跨库逻辑看起来都正常；上线双库后，才发现 logDB.Create() 在事务函数里没被回滚，或者时间字段全变成 UTC——因为日志库 DSN 漏写了 loc=Local。
