go标准库无法保证跨服务数据一致性，因其缺乏分布式事务支持，database/sql的事务仅限单库，跨服务易导致状态撕裂；saga模式通过本地事务绑定业务与日志、幂等补偿和显式步骤实现可控一致性。
为什么直接用 Go 标准库无法保证跨服务数据一致性
Go 本身不提供分布式事务运行时，database/sql 的 Begin/Commit 只作用于单个数据库连接，跨服务调用时天然隔离。一旦服务 A 提交成功、服务 B 调用失败，就会出现状态撕裂——比如订单创建了但库存没扣减。
常见错误现象包括：最终一致性延迟不可控、补偿逻辑漏写或幂等失效、Saga 流程卡在中间步骤无监控。
- 不要试图用
time.Sleep模拟“等待其他服务完成”——网络延迟和节点故障会让它彻底失效 - 避免在 HTTP handler 中嵌套多个远程
POST并逐个if err != nil回滚——失败点之后的服务调用根本没发出去，所谓“回滚”只是空转 - 别把本地事务和远程调用混在同一
tx.Commit()作用域里——Go 不会帮你传播事务上下文
Saga 模式在 Go 中的最小可行落地方式
Saga 是目前 Go 微服务中最可控的一致性方案：每个服务只管自己的 DB，用正向操作 + 显式补偿来串联流程。关键不是“多酷”，而是“每步可查、每步可重试、每步有超时”。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 用结构体明确定义每个步骤：
type ReserveStockStep struct{ OrderID string; SkuCode string; Qty int }，而不是传 map 或 JSON 字符串 - 补偿操作必须是幂等的，推荐用
WHERE status = 'reserved' AND order_id = ?做条件更新，避免重复释放 - 正向操作和补偿操作共用同一张表（如
saga_log），字段含step_name、payload、status（pending/compensated/succeeded）、created_at、retried_at - 用
github.com/ThreeDotsLabs/watermill或原生net/http+context.WithTimeout发送步骤指令，别用阻塞式同步调用链
如何让本地事务和 Saga 步骤真正绑定
核心矛盾：本地 DB 提交了，但 Saga 日志写失败 → 后续无法触发补偿；反之，日志写成功但本地事务回滚 → 留下脏日志。必须原子化这两件事。
Go 中最简方案是“本地事务内写 saga_log 表 + 业务表”，例如：
tx, _ := db.Begin()
_, _ := tx.Exec("INSERT INTO saga_log (...) VALUES (?, ?, ?, ?)", "reserve_stock", payload, "pending", time.Now())
_, _ := tx.Exec("UPDATE inventory SET locked_qty = locked_qty + ? WHERE sku = ?", qty, sku)
tx.Commit()
这样只要事务提交成功，Saga 日志和业务状态就一定一致。注意：
- 不要用 NoSQL 存 saga_log —— 缺乏强事务语义，无法与 MySQL/PostgreSQL 本地事务对齐
- 避免在事务中调用外部 HTTP 接口 —— 超时或 panic 会导致事务 hang 住或意外 rollback
- 如果必须异步触发下一步（如发 Kafka），应在事务提交后由独立 goroutine 拉取
saga_log WHERE status = 'pending'处理，而非在事务内发送
什么时候该放弃最终一致性，改用 TCC 或消息队列+本地事务表
当业务要求“秒级可见一致”（如支付扣款后用户余额必须立刻为 0），Saga 的补偿延迟和人工介入成本就不可接受。这时需更重的机制：
- TCC：适合有明确 Try/Confirm/Cancel 边界的场景（如账户服务），但 Go 生态缺乏成熟框架，需自己实现
TryTransfer、ConfirmTransfer、CancelTransfer三组接口，并保证 Confirm/Cancel 的幂等与超时重试 - 本地事务表 + 消息队列：在业务 DB 写完后，用同一事务插入
outbox表，再由单独消费者读取并投递到 Kafka/RocketMQ。这是目前 Go 项目中平衡可靠性与复杂度的主流选择，依赖github.com/jmoiron/sqlx和github.com/segmentio/kafka-go即可快速搭建 - 切记：无论选哪种，都必须暴露
/saga/status?order_id=xxx这类诊断接口——线上出问题时，没人能靠日志拼出完整链路
分布式事务没有银弹。Saga 适合大多数订单、库存类场景；TCC 适合金融级强一致；而本地事务表 + 消息队列更适合需要解耦又不愿引入新中间件的团队。最难的从来不是代码怎么写，而是怎么让每个步骤的状态变化可观察、可追溯、可人工干预。
