GORM 不支持两阶段提交（2PC），其 Transaction() 仅为单数据库连接的 BEGIN/COMMIT/ROLLBACK 封装，无协调者、无 prepare 阶段，无法实现跨库/跨服务分布式事务；需借助 TCC、消息队列或 Seata 等外部机制。
GORM 本身不支持两阶段提交（2PC），它只是 ORM 层，事务控制完全依赖底层数据库引擎。MySQL、PostgreSQL 等单机数据库原生不提供跨库/跨服务的 2PC 能力；所谓“GORM 配两阶段提交”，本质是误用概念，容易导致数据不一致或连接悬挂。
为什么 GORM.Transaction 不是两阶段提交
Transaction() 只是对单个数据库连接上 BEGIN/COMMIT/ROLLBACK 的封装，属于单阶段原子操作。它没有协调者（Coordinator）、没有 prepare 阶段、不涉及其他资源管理器（如另一个 MySQL 实例、Redis、消息队列），因此和分布式事务标准定义中的 2PC 完全无关。
- 调用
db.Transaction(...)时，GORM 拿到的是一个复用当前连接的*gorm.DB，所有操作都在同一 DB 连接上下文内完成 - 即使你手动在两个不同
*gorm.DB实例（比如指向不同 MySQL 实例）上调用Transaction()，它们之间也无任何状态同步或协调机制 - 一旦第一个事务
Commit()成功、第二个失败，GORM 不会自动回滚前者——这就是典型的“部分提交”风险
想在 Go 项目里做真正可靠的跨服务事务，得绕开 GORM 直接集成
如果你的业务确实需要跨多个数据源（例如：订单库 + 库存库 + 积分库），必须引入外部协调机制，GORM 只能作为各环节的执行工具，不能承担事务编排职责：
- 用
github.com/micro/go-micro/v2/store或自研 TCC 框架实现 Try-Confirm-Cancel 流程，每个步骤用 GORM 执行本地事务，失败时调 Confirm/Cancel - 基于消息队列（如 Kafka/RocketMQ）实现可靠事件驱动：主事务成功后发「订单创建成功」事件，下游服务监听并执行库存扣减，失败则重试+死信告警
- 若强一致性不可妥协且基础设施支持，可接入 Seata（需部署 Server + AT 模式代理），但 GORM 需配合其 JDBC 代理层使用，Go 客户端目前无官方 AT 支持，只能走 XA 模式（要求数据库开启 XA，并用
database/sql原生驱动）
单数据库内提升事务可靠性，这才是 GORM 能干好的事
与其纠结“怎么配 2PC”，不如把单库事务用扎实。这些点才是线上事故高发区：
- 避免在
Transaction()闭包里调用 HTTP 请求、写文件、发消息等非数据库操作——超时或 panic 会导致事务卡住，连接池耗尽 - 所有数据库操作必须用传入的
tx *gorm.DB，绝不能混用原始db实例，否则脱离事务上下文 - 设置事务超时：
ctx, cancel := context.WithTimeout(context.Background(), 5*time.Second)，再传给db.WithContext(ctx).Transaction(...) - 对长事务（如批量导入）启用
ReadUncommitted隔离级别降低锁竞争：tx.Session(&gorm.Session{PrepareStmt: true}).Select("gorm:query_option", "SET TRANSACTION ISOLATION LEVEL READ UNCOMMITTED")
真正难的不是“怎么写两阶段”，而是判断哪些场景根本不需要它——绝大多数 Gin + GORM 电商项目，用好本地事务 + 最终一致性事件 + 补偿任务，比硬上 2PC 更稳定、更易维护。别被术语带偏，先看清楚你的数据边界在哪。
