gorm 的 db.transaction() 无法跨数据源，因其底层依赖单个 *sql.tx，严格绑定一个数据库连接；多库场景需手动协调多个独立事务，配合超时控制、幂等设计与最终一致性补偿机制。
db.Transaction() 无法跨数据源，这是根本限制
GORM 的 db.Transaction() 只作用于单个 *gorm.DB 实例，它底层依赖 *sql.Tx，而该对象严格绑定到一个数据库连接。当你有 MySQL + PostgreSQL、或两个独立 MySQL 实例时，db.Transaction() 对第二个数据源完全无效——调用 db2.Transaction() 是另一个孤立事务，彼此无感知。
常见错误现象：db1.Transaction() 里嵌套 db2.Create()，看起来都“成功”了，但其中一端失败后另一端已提交，数据永久不一致。
- 不要尝试用
db1.Transaction()包裹对db2的操作 - 不要在事务闭包里直接用全局
db2，必须显式传入事务对象（如tx2）并确保它来自db2.BeginTx() - 若业务强依赖多库原子性（如订单库+积分库），必须放弃本地事务，改用 Saga 模式或 TCC
手动 BeginTx 配合 context 超时是唯一可控路径
跨数据源场景下，你只能自己协调多个 *sql.Tx，靠代码逻辑保证“全提交”或“全回滚”。关键不是语法，而是错误分支的全覆盖。
必须用 db.BeginTx(ctx, &sql.TxOptions{}) 而非 db.Begin()：前者支持 context.WithTimeout，避免某个库卡死导致整个流程 hang 住；后者无超时，连接池极易耗尽。
- 每个数据源都需独立
BeginTx，各自配defer tx.Rollback()作为 panic 和提前 return 的兜底 - 所有
tx1.Commit().Error和tx2.Commit().Error都要检查，任一失败就必须对已成功提交的 tx 手动回滚（注意：已 Commit 的无法 rollback，所以实际是“尽力而为”） - MySQL 的
innodb_lock_wait_timeout和 Go 层context.Timeout必须协同，例如设为 3s，否则 DB 等锁 50s，Go 早放弃了
FOR UPDATE 锁只在本库生效，别指望它同步多源
有人试图在事务里对 MySQL 表加 SELECT ... FOR UPDATE，再操作 PostgreSQL，以为能“锁住业务状态”。这是错觉——PostgreSQL 根本不知道 MySQL 的锁，且锁本身不跨网络、不跨进程。
真正需要的是业务层状态标记：比如在 MySQL 订单表新增 status = 'processing' 字段，用唯一约束或乐观锁（version）控制并发；等 PostgreSQL 积分扣减成功后，再更新为 'done'。失败则靠定时任务扫描 'processing' 订单做补偿。
-
FOR UPDATE只防本库并发修改，对多源无意义 - 跨源一致性靠最终一致性 + 补偿 + 幂等，不是靠数据库锁
- 所有跨库写操作必须带幂等 key（如
order_id + action_type），防止重试重复扣款
嵌套事务（SavePoint）对多数据源毫无帮助
GORM 的 tx.Begin() 在已有事务中调用，只是创建 SavePoint，本质仍是单连接上的局部回滚点。它对第二个数据源 db2 完全不可见——tx1.SavePoint("sp1") 和 tx2.SavePoint("sp1") 是两套独立机制，无法联动。
试图用 SavePoint 实现“MySQL 失败就回滚 PostgreSQL”的想法，在技术上不可行。SavePoint 不是分布式事务协调器，它连两个连接都管不了，更别说两个数据库实例。
- SavePoint 只适用于单库内部分操作失败需局部回退（如校验失败撤回中间状态）
- 多数据源下，SavePoint 和普通
BeginTx没本质区别，都不能解决跨库原子性 - 一旦涉及多库，必须接受“没有银弹”，设计时就要把失败当作常态来处理
