微服务中GORM应为每个数据源创建独立*gorm.DB实例，统一初始化逻辑与连接池策略而非共用变量；需正确导入驱动、配置DSN参数、设置连接池及生命周期，并确保各实例显式关闭。
微服务里用 GORM 做数据库连接，根本不存在“统一管理一个连接”的合理场景——强行共用 *gorm.DB 变量只会导致查错库、事务失效、panic 或连接泄漏。真正的统一，是统一初始化逻辑、统一健康检查、统一连接池策略，而不是统一变量。
多个 *gorm.DB 实例必须各自声明、各自初始化
常见错误是写一个全局 var db *gorm.DB，然后在不同地方反复调用 gorm.Open() 赋值。后一次覆盖前一次，userDB.Create() 可能实际写进日志库，或者 logDB.Transaction() 里查不到用户数据。
- 每个数据源（MySQL 用户库、PostgreSQL 订单库、SQLite 配置库）都该有专属变量：比如
userDB、orderDB、configDB - 初始化函数必须返回
(*gorm.DB, error)，不能塞进func init()——失败时无法透出错误，日志里只看到 “nil pointer dereference” - 如果用依赖注入（如 Wire/fx），给每个实例绑定唯一类型别名，例如
type UserDB *gorm.DB，否则容器会把它们当同一类型混用
gorm.Open() 的 DSN 和驱动必须严格配对
传 mysql.Open(dsn) 却填 PostgreSQL 的 DSN，GORM 不会在 Open 阶段报错，而是在第一次 .First() 时卡住或返回模糊错误，比如 "invalid connection" 或直接超时。
- 确认已导入对应驱动：
import _ "gorm.io/driver/mysql"（MySQL）、import _ "gorm.io/driver/postgres"（PostgreSQL）——下划线不能漏，否则静默失败 - DSN 关键参数不能少：
?charset=utf8mb4&parseTime=True&loc=Local（MySQL）、?sslmode=disable（PostgreSQL），缺了某些版本握手阶段就 hang 住 - PostgreSQL 用户名/密码含
@或/时，必须用url.QueryEscape()编码，否则解析失败且错误提示毫无指向性（常报"pq: password authentication failed"）
连接池参数必须按库单独配置，不能共享默认值
gorm.Open() 返回的 *gorm.DB 底层是 *sql.DB，它的连接池默认值极小：MaxIdleConns=2、MaxOpenConns=0（即无上限但受系统限制），压测时极易出现 dial tcp: connect: cannot assign requested address 或慢查询堆积。
- 每个
*gorm.DB初始化后，立刻调用：db.DB().SetMaxIdleConns(10)、db.DB().SetMaxOpenConns(50)，数值按服务 QPS 和数据库规格调整，不要硬编码 -
SetConnMaxLifetime(30 * time.Minute)和SetConnMaxIdleTime(10 * time.Minute)要配对设，避免 MySQL 的wait_timeout中断长连接后 GORM 不重连 - 如果 DSN 含
%字符（比如启用interpolateParams=true），需提前转义，否则解析失败
事务和上下文只作用于单个 *gorm.DB 实例
在 userDB.Transaction() 里调用 logDB.Create()，后者完全游离在事务外——哪怕两个库连的是同一台 PostgreSQL 实例，也做不到跨库原子性。这不是 bug，是设计使然。
- GORM 的事务机制只管理单个连接池内的连接复用和提交/回滚，不跨实例协调
-
db.WithContext(ctx).Transaction()中的ctxtimeout 只约束当前 DB 的执行时长，不影响其他实例 - 硬要“伪事务”？可用
userDB.Session(&gorm.Session{NewDB: true}).Begin()控制本库内连接隔离，但对logDB依然无效 - 跨库一致性得靠业务层补偿：比如先写主库成功，再异步写日志库；失败则发告警 + 人工介入，别指望 ORM 解决
最易被忽略的一点：GORM 不提供跨库连接生命周期管理。你定义了 userDB 和 orderDB，就得自己确保它们在服务退出前都调用 db.Close()，否则连接不释放，K8s 里滚动更新时旧 Pod 的连接可能持续占用数据库资源数小时。
