事务无法跨数据库实例生效，这是 GORM 的硬性限制，因每个 gorm.DB 绑定独立的 sql.DB 连接池，*sql.Tx 仅作用于单库，多库需业务层协同实现最终一致。
事务无法跨数据库实例生效，这是 GORM 的硬性限制，不是配置问题，也不是版本缺陷。
为什么 db.Transaction() 只对一个库起作用
GORM 的 Transaction 方法底层依赖 *sql.Tx，而每个 *gorm.DB 实例都绑定独立的 *sql.DB 连接池。调用 userDB.Transaction() 时，GORM 只会从 userDB 对应的连接池里取连接、开启事务，logDB.Create() 这类操作完全走另一套连接池和事务上下文。
常见错误现象：
- 代码看似在一个
Transaction闭包里，但日志库写入成功、主库回滚了，数据不一致 - PostgreSQL 报错
ERROR: current transaction is aborted, commands ignored until end of transaction block，其实是两个库混用了连接或 ctx - 本地单库测试全绿，上线双库后定时任务偶尔漏写日志表，查不到明显 panic
根本原因：事务边界由 *sql.Tx 定义，而它只属于某一个 *sql.DB —— GORM 不可能、也不应该跨驱动协调多个物理连接。
多数据源下事务的可行做法
没有“跨库事务”，只有“业务层协同”。你得接受这个前提，再选合适策略：
- 主库强一致性 + 日志库最终一致：先
userDB.Transaction()提交用户变更，成功后再异步发消息（如 Kafka）触发logDB.Create()；失败则告警+人工补偿 - 使用 SavePoint 做单库内分段控制：比如在
userDB事务中，用tx.Session(&gorm.Session{AllowGlobalUpdate: true}).Create()隔离部分操作，但依然不影响logDB - 放弃 ORM 层事务，改用原生 SQL 手动管理连接：获取
userDB.DB().Conn(ctx)和logDB.DB().Conn(ctx)，自己拼Begin/Commit/Rollback，但需自行处理超时、panic 捕获、连接归还 —— 工程代价远高于收益，不推荐
注意：db.WithContext(ctx).Transaction() 中的 ctx timeout 只约束当前库执行时长，对其他 *gorm.DB 实例完全无效。
容易被忽略的初始化陷阱
事务失效往往不是写法错，而是实例本身没管好：
- 所有
*gorm.DB必须各自调用gorm.Open()，不能复用全局变量var db *gorm.DB赋值覆盖 —— 后一次会把前一次的连接池和事务状态冲掉 - 若用依赖注入（如 fx），必须为每个库定义唯一类型别名，例如
type UserDB *gorm.DB和type LogDB *gorm.DB，否则容器会当成同一类型注入 -
func init()里初始化 DB 是危险的：失败时无法返回 error，日志无堆栈，线上排查像盲人摸象；应改用显式函数如InitUserDB() (*gorm.DB, error)
连接池参数（SetMaxOpenConns 等）也必须在每个 *gorm.DB 初始化后立刻设置，不能共用一套逻辑 —— 某个慢查询库占满连接，会拖垮整个服务。
真正麻烦的从来不是“怎么写事务”，而是“怎么让每个 *gorm.DB 实例从进程启动那一刻起就干净、独立、可追踪”。一旦漏掉初始化隔离或类型混淆，后面所有事务逻辑都会在无声中失效。
