多个 *gorm.db 实例必须独立初始化，不可复用全局变量；需为每个库定义专属变量（如userdb、logdb），分别调用gorm.open()，并显式配置连接池、dsn、驱动导入及健康检查。
多个 *gorm.DB 实例必须独立初始化，不能复用或覆盖
微服务里连 MySQL 和 PostgreSQL 两个库，最常见错误是只声明一个全局 var db *gorm.DB，然后反复调用 gorm.Open() 赋值——后一次会覆盖前一次，导致查错库、事务失效甚至 panic。GORM 不自动管理多实例生命周期，每个库都得有自己专属变量。
- 正确做法：显式定义不同变量名，比如
userDB、logDB、cacheDB，各自调用gorm.Open() - 别在
func init()里初始化：失败时无法返回错误，日志难定位；改用带 error 返回的初始化函数，比如InitUserDB() (*gorm.DB, error) - 如果用依赖注入（如 fx/wire），给每个
*gorm.DB绑定唯一类型别名，例如type UserDB *gorm.DB，否则容器会把它们当成同一类型混用
gorm.Open() 的第一个参数和 DSN 必须严格匹配驱动
传 mysql.Open(dsn) 却填 PostgreSQL 的 DSN，GORM 不会立刻报错，而是在第一次查询时卡住或返回模糊错误（如 "invalid connection" 或直接 timeout）。根本原因是驱动注册和方言解析不匹配。
- 确认已导入对应驱动：MySQL 用
import _ "gorm.io/driver/mysql"，PostgreSQL 用import _ "gorm.io/driver/postgres"——下划线不能漏，否则静默失败 - DSN 中关键参数不能少：MySQL 至少含
?charset=utf8mb4&parseTime=True&loc=Local，PostgreSQL 至少含?sslmode=disable，否则某些版本握手阶段就 hang 住 - PostgreSQL 用户名/密码含特殊字符（如
@、/）时，必须用url.QueryEscape()编码，否则解析失败且错误提示毫无指向性（常报"pq: password authentication failed"）
事务只作用于调用它的那个 *gorm.DB 实例
userDB.Transaction() 里调用 logDB.Create()，后者完全游离在事务外——哪怕两个库连的是同一台 PostgreSQL 实例，也做不到跨库原子性。这不是 bug，是设计使然。
- GORM 的事务机制只管理单个连接池内的连接复用和提交/回滚，不跨实例协调
- 硬要“伪事务”？可用
userDB.Session(&gorm.Session{NewDB: true}).Begin()控制本库内连接隔离，但对logDB依然无效 - 跨库一致性得靠业务层补偿：比如先写主库成功，再异步写日志库；失败则发告警+人工介入，别指望 ORM 解决
-
db.WithContext(ctx).Transaction()中的ctxtimeout 只约束当前 DB 的执行时长，不影响其他实例
连接池参数必须按库单独配置，不能共用默认值
默认 MaxOpenConns = 0（无限制）、MaxIdleConns = 2、ConnMaxLifetime = 0（永不过期），在生产环境极易打满数据库连接数，尤其微服务多实例部署时。
- 每个
*gorm.DB都要显式调用db.DB().SetMaxOpenConns(n)和db.DB().SetMaxIdleConns(m)，且n应 ≤ 数据库侧max_connections/ 实例数 -
ConnMaxLifetime建议设为 30~60 分钟，避免中间网络设备（如 PgBouncer、Nginx）静默断连后 GORM 还持着死连接 - 若用了 PgBouncer，
pool_mode推荐transaction，并确保 GORM 的MaxOpenConns≤ PgBouncer 的max_client_conn - 记得加健康检查：
db.DB().Ping()应在服务启动和定期探活中调用，失败需触发重连逻辑
