Go中无开箱即用Saga框架，必须手动实现多步骤本地事务加显式补偿的编排模式，每个步骤需本地事务性、幂等补偿、逆序回滚及状态持久化。
Go 没有分布式事务的“开箱即用”方案，所有落地都得靠业务层显式设计——不是语法限制，而是 Go 倾向把边界和权责交还给开发者。
为什么 database/sql 的 BeginTx 解不了跨服务问题
它只管单个 *sql.DB 连接，事务上下文不跨网络、不跨进程、不跨数据库实例。哪怕你用 gorm 或 sqlx 封装得再漂亮，tx.Commit() 成功也只代表本地那张表改写了，对库存服务的 MySQL 或账户服务的 PostgreSQL 完全没影响。
常见错误现象：UPDATE orders SET status='paid' WHERE id=123 执行成功，紧接着 http.Post("inventory-service/deduct", ...) 因网络超时返回失败，但订单状态已变，库存却没扣——这不是代码 bug，是模型误用。
- 别在 HTTP 调用里套
defer tx.Rollback()：下游失败 ≠ 本地该回滚，可能只是暂时抖动 - 别用内存变量（如
map[string]bool）记录各步骤状态：服务重启就丢，Saga 直接中断 - 别假设 “一次请求 = 一个事务”：微服务间调用本质是异步协作，必须接受部分成功
Outbox 模式：最稳的“发消息 + 改状态”原子性保障
核心是让消息写入和业务更新落在同一张数据库里，靠本地事务兜底。不是“先改 DB 再发 MQ”，而是“改 DB 同时往 outbox 表插一条待发事件”。轮询器从 outbox 读、发、删，三步分离，失败可重试。
立即学习“go语言免费学习笔记（深入）”；
关键实操点：
-
outbox表必须和业务表同库：否则INSERT INTO outbox和UPDATE orders无法塞进同一个tx - 插入
outbox前要用SELECT FOR UPDATE锁住对应业务行，防止并发扣减导致重复发事件 - 轮询间隔建议 100ms–500ms：太短压 DB，太长延迟高；可用
time.Sleep+select { case 控制 - 下游接口必须带幂等键，比如 HTTP header
Idempotency-Key: order_123_v1，或 DBUNIQUE (event_id)
示例伪码：
tx, _ := db.BeginTx(ctx, nil)
_, _ = tx.Exec("UPDATE inventory SET available = available - 1 WHERE sku = ? AND available >= 1", "SKU-001")
_, _ = tx.Exec("INSERT INTO outbox (topic, payload, event_id) VALUES (?, ?, ?)", "inventory_deducted", `{"sku":"SKU-001","order_id":"123"}`, "evt_abc123")
tx.Commit()Saga 模式：长流程下补偿逻辑必须落库且独立事务
适合下单→扣库存→发券→通知这类多步链路。每步执行后，状态（如 "reserve_stock:done"）必须存到持久化存储（如 saga_records 表），不能放内存或 Redis（无持久保证）。
容易踩的坑：
- 补偿操作不能复用原事务连接：比如“取消订单”的
UPDATE必须新开*sql.Tx，否则原事务已提交，补偿失败会导致悬挂 - 没做空回滚防护：下游服务收到重复补偿请求（如网络重传），应检查当前订单状态是否已是
cancelled再执行 - 没设重试上限：轮询查状态或调补偿接口，最多 3–5 次，之后进死信队列人工介入，避免无限循环拖垮系统
别指望 context.WithTimeout 自动终止整个 Saga 流程——它只 kill 当前 goroutine，下游服务还在跑，得靠主动查询 + 补偿兜底。
别碰 Seata/Atomikos 这类 Java 中间件的 Go 客户端
它们不是为 Go 设计的：Seata 的 AT 模式要解析 SQL、代理数据源，Go 的 database/sql 没统一 AST 层，拦截不可靠；TCC 要求每个服务暴露 Try/Confirm/Cancel 三套接口，而 Go 微服务通常只有一套 REST/gRPC 业务接口，硬加会显著抬高维护成本。
真实代价：
- 自己补协调器日志存储、悬挂事务清理、分支注册超时机制——等于重写半个 Seata
- gRPC streaming 不等于事务流：流式响应解决不了跨服务原子性，只是传输方式优化
- 用
sync.Map做分布式锁？一扩缩容，锁全失效；该用redis.SetNX或etcd.CompareAndSwap
最终一致性不是妥协，而是把“强一致”的复杂度从框架转移到业务可控制的环节：状态落盘、幂等设计、轮询节奏、对账修复——这些才是 Go 工程师该盯紧的地方。
