多个 GORM 实例怎么共存不冲突
同一个 Go 进程里启动多个数据库连接，最常见错误是全局复用 gorm.DB 实例或误用 gorm.Open 返回的指针做共享。GORM 本身不自带“多租户连接池管理”，每个 DB 实例默认独立维护自己的连接池、回调、日志器和配置——但如果你把它们混着传参、或在中间件里错绑了实例，就会查到别的库、事务不生效、甚至 panic。
- 每个数据库连接必须由独立的
gorm.Open创建，并保存为不同变量（如userDB、logDB），别用var db *gorm.DB全局覆盖 - 避免在
func init()里初始化多个DB：init 是包级单次执行，但 DB 初始化可能失败，错误难捕获；改用显式初始化函数 + 错误返回 - 如果要用依赖注入（比如 fx 或 wire），确保每个
*gorm.DB绑定唯一类型名（如type UserDB *gorm.DB），否则容器会混淆实例
Open 时传错 dialect 导致连接卡死或报错
MySQL、PostgreSQL、SQLite 的 DSN 格式差异大，但更隐蔽的问题是驱动注册和 gorm.Open 第一个参数没对齐。比如用 mysql 驱动却传了 postgres 的 DSN，GORM 不会立刻报错，而是在第一次查询时卡住或返回 "invalid connection"。
- 确认已导入对应驱动：
import _ "gorm.io/driver/mysql"或_ "gorm.io/driver/postgres"，少一个下划线就静默失败 - DSN 中不能漏掉
?charset=utf8mb4&parseTime=True&loc=Local（MySQL）或?sslmode=disable（PostgreSQL），否则某些版本会 hang 在连接握手阶段 - PostgreSQL 的用户名密码若含特殊字符（如
@、/），必须用url.QueryEscape编码，否则解析出错且错误信息极不明确（常表现为"pq: password authentication failed"却密码正确）
事务跨库失效：为什么 Transaction 只在一个库起作用
GORM 的 Transaction 方法只作用于调用它的那个 *gorm.DB 实例，它无法协调多个数据库间的原子性。你写 userDB.Transaction(...)，里面调用 logDB.Create(...) 就完全游离在事务之外——哪怕两个库都在同一台 PostgreSQL 实例上，也不行。
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 跨库事务不是 GORM 能解决的问题，得靠业务层补偿（比如先写主库，成功后再异步写日志库，失败则发告警+人工介入）
- 如果硬要“伪事务”，可用
Session控制单库内连接复用：userDB.Session(&gorm.Session{NewDB: true}).Begin()，但这只是保证本库内事务隔离，不影响其他 DB 实例 - 注意
db.WithContext(ctx).Transaction(...)中的 ctx 若带 timeout，只影响当前 DB 的事务执行时长，和其他 DB 无关
连接池配置不分离导致某库拖垮整个服务
默认情况下，每个 *gorm.DB 实例都自带独立连接池，但很多人忽略调用 DB.Config.ConnPool 或直接改 sql.DB 设置，结果所有库共用底层 sql.DB 的 SetMaxOpenConns，一旦某个分析型查询占满连接，API 库就全卡住。
立即学习“go语言免费学习笔记（深入）”；
- 每个
DB初始化后必须单独设置连接池：userDB.DB().SetMaxOpenConns(50)、logDB.DB().SetMaxOpenConns(10) - 别在
gorm.Open后立刻调db.DB().SetConnMaxLifetime，要等db.Error == nil再操作，否则db.DB()可能为 nil - PostgreSQL 对连接数敏感，
max_connections设为 100 时，Go 侧总SetMaxOpenConns加起来最好不超过 60，留余量给 migration、admin 工具等
多库配置真正的难点不在初始化，而在运行时哪条 SQL 跑在哪张表、哪个实例上——模型定义里没写死 TableName 或没配 Table 方法，很容易查串库。这点没人提醒，但线上出过三次故障。
