GORM原生不支持分布式事务，仅限单数据库连接；正确方案是本地事务+消息表实现最终一致性，或收窄事务边界。HTTP调用、Redis写入、Kafka生产等I/O操作必须移出事务体，改用AfterCommit或消息表异步处理。
分布式场景下 GORM 事务本身不适用
GORM 的 db.Transaction() 和 tx.Begin() 都只作用于单个数据库连接，无法跨服务、跨数据库实例、跨网络节点协调状态。所谓“分布式事务”，GORM 原生根本不支持——它连本地多 DB 实例的事务都做不到（比如 MySQL + PostgreSQL 混合写），更别说跨微服务了。
常见误操作是：在 A 服务调用 B 服务前开一个 tx := db.Begin()，然后发 HTTP 请求让 B 也“开启事务”，以为这样就构成了分布式一致性。结果是 A 提交了，B 失败了，或反之；没有两阶段提交（2PC）、没有 Saga 协调器、没有消息中间件兜底，数据必然不一致。
真正能落地的方案只有两类：要么放弃强一致性，改用最终一致性；要么把事务边界收窄到单库内，其余逻辑移出事务体。
哪些操作必须从 GORM 事务里踢出去
HTTP 调用、Redis 写入、Kafka 生产消息、文件存储、调用其他 gRPC 接口——这些全部不能放在 db.Transaction() 函数体内。它们不是原子操作，也不受数据库事务控制，一旦失败，tx.Rollback() 对它们完全无效。
容易踩的坑：
- 在事务里直接
http.Post(...)同步通知下游，超时导致事务 hang 死，连接池耗尽 - 用
tx.Exec("INSERT INTO cache_log ...")伪装缓存更新，但缓存和 DB 状态实际已脱钩 - 调用
tx.AfterCommit()时传错tx实例（比如用了db而非事务句柄），钩子根本没注册上
正确做法是：把 I/O 操作移到 tx.AfterCommit() 中，或写入本地消息表后由独立消费者投递；失败时靠幂等 + 补偿，而不是指望回滚。
本地事务 + 消息表 是最现实的折中方案
想在分布式系统里保数据可追溯、可补偿，推荐用“本地事务 + 消息表”模式。核心是：所有需要跨系统联动的动作，先落库（和主业务在同一事务），再异步触发。
示例流程：
- 用户下单：在
db.Transaction()里完成orders插入 +outbox_messages插入（同一事务） - 事务成功后，定时任务或监听
outbox_messages表，把消息发到 Kafka - 下游服务消费后，更新
outbox_messages.status为processed
关键点：
-
outbox_messages必须和业务表在同一个数据库、同一个事务中，否则就失去原子性 - 不要用 UUID 当消息 ID——MySQL 的
LAST_INSERT_ID()或 PostgreSQL 的RETURNING id更可靠 - 避免在事务里做任何
SELECT FOR UPDATE跨表锁，否则容易和 outbox 写入争抢行锁
别碰分布式事务框架封装的 “GORM 插件”
有些第三方库声称支持 “GORM 分布式事务”，底层其实是包装了 Seata 或 Atomikos 的客户端，强行把 GORM 的 tx 注入到全局事务上下文。这类方案在生产环境极难调试：
- 版本兼容差：GORM 1.30.3 和 Seata 1.8.x 的 context 透传逻辑经常断裂
- panic 捕获失效：GORM 的
Transaction()recover 机制和分布式框架的 rollback hook 冲突，导致部分分支静默丢弃 - 连接池污染：一个
tx实例被多个分布式分支复用，tx.Commit()可能提前释放连接
真实项目里，与其花两周调通一个“理论上能用”的封装，不如花两天写清楚 outbox 表结构 + 消费者重试逻辑。最终一致性的工程成本，远低于强一致的运维复杂度。
最常被忽略的一点：事务不是越长越好，而是越短越好。哪怕只是把日志记录、指标上报、缓存失效这些动作移出事务体，都能显著降低死锁率和连接占用时间。
