本地事务在微服务中失效是因为sql事务仅保障单库ACID，跨服务调用无法协调，导致部分成功引发数据不一致；Saga模式通过可补偿的本地事务链实现最终一致性，是go微服务中最现实的选择。
为什么本地事务在微服务里直接失效
微服务拆分后，一个业务操作常涉及多个服务的数据库，sql.Tx 只能保证单库 ACID，跨服务时 commit 一半失败，就会出现状态不一致。比如订单服务扣减库存成功，但支付服务写入失败，用户没付款却库存已扣——这不是程序 bug，是架构约束下的必然结果。
- 不要试图用
database/sql的事务包裹跨服务调用，它对远程 http/gRPC 调用完全无感知 - 两阶段提交（2PC）在 Go 生态中几乎没有成熟、轻量、生产可用的实现，且会显著拖慢性能、提高运维复杂度
- Saga 模式不是“替代方案”，而是当前 Go 微服务中最现实的选择：用可补偿的本地事务链，换取最终一致性
Saga 模式在 Go 中怎么落地（正向 + 补偿流程）
核心是把一个分布式操作拆成一系列本地事务步骤，每步都配一个对应的补偿操作（undo）。Go 里没有框架强制你写补偿逻辑，得靠结构设计兜住。
- 每个服务暴露两个接口：
CreateOrder（正向）和CancelOrder（补偿），两者都必须是幂等的 - 用消息队列（如 kafka/rabbitmq）或数据库表（
saga_log）记录执行进度，避免因服务重启丢失状态 - 推荐用状态机管理 Saga 流程，例如用
github.com/looplab/fsm定义pending → confirmed → cancelled等状态，防止重复执行或跳步 - 示例片段：
if err := orderSvc.Create(ctx, req); err != nil { // 记录失败，触发补偿链路 sagaLog.FailStep("create_order", err) return compensateInventory(ctx, req.OrderID) }
什么时候该用本地消息表，而不是直接发 MQ
直接调 producer.Send() 发消息，若 DB commit 成功但网络抖动导致消息丢失，就会漏掉后续步骤。本地消息表本质是把“发消息”也变成一个本地事务操作。
- 在同一个事务里：更新业务表 + 插入一条
message记录（含目标 topic、payload、status=’pending’） - 另起一个定时任务或监听 goroutine，轮询
message表中status = 'pending'的记录，调用 MQ 发送并更新 status = ‘sent’ - 注意：轮询间隔和重试策略要设合理，太短压 DB，太长延迟高；建议用
time.Sleep+ 指数退避，而非固定间隔 - 如果用 Kafka，可考虑
github.com/segmentio/kafka-go的事务支持，但需 Kafka 0.11+ 且开启transactional.id，实际部署约束多，不如本地表通用
补偿失败怎么办：死信 + 人工干预不是备选，是必选项
无论设计多严谨，补偿操作本身也可能失败（比如库存服务宕机超时）。这时候不能让 Saga 卡死或无限重试。
立即学习“go语言免费学习笔记（深入）”；
- 补偿失败三次后，自动将记录转入
saga_dead_letter表，带上完整上下文（trace_id、原始 payload、错误堆栈） - 配套一个简单的 Web 页面或 CLI 工具，供运维查看、手动重试或标记为“忽略”（例如用户已主动取消，无需再扣库存）
- 关键点：所有补偿函数必须带
context.Context并响应 cancel，避免 goroutine 泄漏；日志里务必打上trace_id，否则排查时根本串不起链路 - 别指望“100% 自动恢复”，分布式系统里，可观测性 + 快速人工介入路径，比追求理论上的全自动更重要