多个*gorm.db实例必须独立初始化，不可复用同一变量；需为每个库定义专属变量（如userdb、logdb），分别调用gorm.open并显式配置连接池、dsn、驱动导入及健康检查。
多个 gorm.DB 实例必须独立初始化，不能复用同一个变量
常见错误是声明一个全局 var db *gorm.DB，然后在不同地方反复赋值，比如先 db = gorm.Open(...) 连 MySQL，再 db = gorm.Open(...) 连 PostgreSQL——这会导致后一次覆盖前一次，所有模型操作都跑到最后一个库上，且连接池参数、日志器、回调全部错乱。
正确做法是为每个数据库定义独立变量：
-
var userDB *gorm.DB（主业务库） -
var logDB *gorm.DB（日志库） -
var reportDB *gorm.DB（报表库）
每个变量都由单独的 gorm.Open 创建，传入对应驱动和 DSN。GORM v2 不会自动共享连接池或配置，所以变量名隔离就是最基础的安全边界。
DSN 和驱动必须严格匹配，否则连接会卡死或静默失败
比如用 mysql.Open(dsn) 却传了 PostgreSQL 的 DSN：postgres://user:pass@localhost:5432/db，GORM 不会在 Open 时报错，而是在第一次查询时 hang 住或返回 "invalid connection"。
检查要点：
- 确认已导入对应驱动：
import _ "gorm.io/driver/mysql"或import _ "gorm.io/driver/postgres"—— 下划线不能少，否则驱动不注册 - MySQL DSN 必须带
?charset=utf8mb4&parseTime=True&loc=Local，漏掉parseTime会导致 time.Time 字段解析失败 - PostgreSQL DSN 中用户名/密码含
@或/时，必须用url.QueryEscape编码，否则解析出错且错误提示完全误导（如显示pq: password authentication failed）
事务无法跨 gorm.DB 实例生效，别指望 Transaction() 能协调多库
写 userDB.Transaction(func(tx *gorm.DB) error { userDB.Create(...); logDB.Create(...) }) 是无效的：只有 userDB.Create 在事务内，logDB.Create 完全游离在外，甚至可能连到另一台物理机器。
真实约束：
-
Transaction只作用于调用它的那个*gorm.DB实例 - 跨库原子性不存在于 GORM 层，必须靠业务补偿（例如先写主库成功，再发消息异步写日志库；失败则触发告警+人工核对）
- 若需单库内连接复用（如避免事务中新建连接），可用
userDB.Session(&gorm.Session{NewDB: true}).Begin()，但这不解决跨库问题
连接池参数要显式配置，别依赖默认值
GORM v2 虽自动管理连接池，但默认最大连接数是 10，空闲连接数是 1，生产环境极易打满。尤其多数据库共存时，每个实例都按默认值开池，总连接数会翻倍。
初始化时必须显式设置：
- 调用
db.DB().SetMaxOpenConns(30) - 调用
db.DB().SetMaxIdleConns(10) - 调用
db.DB().SetConnMaxLifetime(60 * time.Second)
注意：db.DB() 返回的是底层 *sql.DB，不是 *gorm.DB；这些设置必须在 gorm.Open 成功后立即执行，晚了可能已有连接被创建。
最容易被忽略的是驱动注册和 DSN 格式的一致性——它不报错，但会让整个连接流程卡在不可见的位置；还有就是把多个 *gorm.DB 当成可互换的“数据库句柄”，其实它们之间完全隔离，连事务上下文都不通。
