GORM本地事务无法跨微服务RPC传播，因其仅作用于单个*gorm.DB连接，RPC调用即切换进程、连接池与数据库实例；应放弃强一致幻想，改用幂等接口、预扣锁、异步对账等最终一致性方案。
微服务 RPC 调用链路中，GORM 的本地事务无法跨服务传播，也根本不能“拆解”——它只作用于单个 *gorm.DB 实例的当前连接，RPC 一跳就断。你真正要解决的，是「如何在分布式调用中保持数据一致性」，而不是强行把事务切开。
为什么 GORM.Transaction() 在 RPC 链路里完全失效
GORM.Transaction() 底层依赖数据库连接的 Begin()/Commit()，而这个连接只属于当前服务、当前 *gorm.DB 实例。一旦调用下游服务（比如通过 gRPC），控制权就移交到另一个进程、另一个数据库连接池、甚至另一套数据库实例上。
- 你在
user-service里userDB.Transaction(...)，里面调用orderClient.CreateOrder()—— 后者用的是自己的orderDB，完全不在同一事务上下文 - 即使两个服务连的是同一台 PostgreSQL，GORM 也不会、也不能帮你协调跨进程的两阶段提交（2PC）
- 试图用
context.WithValue(ctx, txKey, tx)把事务对象塞进 RPC 上下文（如RpcContext）是危险且无效的：下游拿不到原始连接句柄，反序列化后只剩空壳
RPC 调用中该用什么替代本地事务
必须放弃「强一致事务」幻想，改用面向业务的最终一致性方案。关键不是“怎么传事务”，而是“怎么设计补偿路径”。
- 核心操作前置：比如“下单”必须先在本服务完成库存预扣（写入
inventory_locks表），再发 RPC 调用创建订单；失败则释放锁 - 显式引入幂等键：所有 RPC 接口入参必须带
idempotency_key（如 UUID），下游服务用数据库唯一索引或 Redis SETNX 拦截重复请求 - 异步对账兜底：定时任务扫描状态不一致的记录（如订单已创建但支付未回调），触发人工介入或自动补偿（如调退款接口）
- 避免跨库事务伪需求：如果真需要“用户扣款 + 订单落库”原子性，应合并为一个服务，而不是拆成
payment-service和order-service后硬凑
哪些地方最容易误以为能“拆事务”
这些做法看似合理，实则埋雷：
- 在 RPC 请求体里传
tx_id字段，下游服务尝试用它查本库事务状态 ——tx_id是 MySQL 内部 ID，跨连接不可见，且生命周期极短 - 用
db.Session(&gorm.Session{NewDB: true})生成新 DB 实例再传给下游 —— 这只是新开一个连接，和上游事务零关系，还可能耗尽连接池 - 把多个
*gorm.DB实例都注册到同一个全局事务管理器（如自定义TxManager）—— GORM 不提供跨实例事务 API，这种封装纯属自我安慰 - 依赖消息队列（如 Kafka）的“事务消息”来模拟事务 —— 它只保证“发消息”和“本地 DB 写入”的原子性，不保证下游消费逻辑成功，仍需下游幂等+重试
最常被忽略的一点：事务边界必须和限界上下文对齐。如果你发现一个业务流程总得横跨三个服务加事务，问题大概率不在技术选型，而在服务拆分本身错了——那个流程本该属于同一个聚合根。
