saga是go中唯一可落地的分布式事务方案，需手动实现状态持久化（必须用postgresql/mysql）、幂等控制、补偿可重入及行级锁保障；禁用内存/redis存状态、禁用并发执行、禁用静默跳过补偿。
Go 语言没有分布式事务原生支持，Saga 是当前唯一可落地的方案，但它不是调一个库就能跑通的“功能”，而是必须手动实现状态持久化、幂等控制与补偿可重入的一套约束体系。
Go 中 Saga 的状态必须落库，不能放内存或 Redis
进程重启、节点宕机后，如果 Saga 状态只存在内存或 Redis 里，已执行的 Do 步骤无法被感知，补偿逻辑彻底失效，事务就“悬挂”了。这不是理论风险，是生产环境高频故障点。
- 必须用 PostgreSQL 或 MySQL 建
saga_instances表，至少含字段：gid（UUID）、status（如pending/step2_done/compensating）、current_step、payload（JSON）、last_error - 每次推进前，要用
SELECT ... FOR UPDATE加锁读取并更新状态，避免并发写覆盖 - 别用
sync.Map或redis.Set("saga:123", "step2_done")—— 它们不提供事务性写入保障，也不支持行级锁 - 状态更新和正向操作（如 DB 写入）必须在同一个本地事务中提交，否则可能丢状态或丢业务数据
每个 Do/Undo 接口必须带幂等键，且 Undo 要支持空回滚
网络重试会让同一请求打多次，没幂等控制的 Do 会重复扣款、重复锁库存；而没空回滚的 Undo 则会在原 Do 根本没执行时，强行发起退款或释放，导致双花或报错中断。
Golang Spf13 Viper
下载
Go 配置库，使用 spf13/viper — 分层优先级（flag > env >file > KV > default），提供 BindPFlag/BindPFlags、SetEnvPrefix + SetEnvKeyReplace 等功能。
- 幂等键要包含业务标识 + 步骤名，例如
order_id:O123:reserve_stock，不能只用order_id:O123—— 否则支付和发货共用一个 key，会互相干扰 - Do 接口应使用带条件的原子 SQL，如
UPDATE inventory SET locked = locked + 1 WHERE sku = ? AND available >= 1 AND status = 'available'，而不是先查再更新 - Undo 接口第一件事是查下游当前状态：比如
RefundService.RollbackPayment(id)必须先查支付记录是否已是refunded，是则直接返回，不调第三方 - 所有接口响应体必须有明确的
result字段（如{"result": "SUCCESS"}），DTM 或自研协调器只认这个字段做判断
Saga 编排必须串行驱动，禁用 goroutine 池和同步阻塞
Saga 不是并发任务流，而是强依赖的状态机。第 3 步能否执行，取决于第 2 步是否成功且状态已落库。用 goroutine + WaitGroup 或 channel 等结果，会破坏顺序性，让补偿在正向步骤完成前就触发。
- 不要写
go doStep3()+wg.Wait()—— 这等于放弃 Saga 的语义保证 - 正确方式只有两种：
if saga.Status == "step2_done" { doStep3() }（DB 轮询驱动），或监听 MQ 事件（如 Kafka topicsaga.step2.done） - DTM 等协调器要求每个子事务的
Action和CompensateURL 必须是绝对路径，例如http://inventory-svc:8080/v1/inventory/deduct，不能是/v1/inventory/deduct - TransOut 和 TransIn 必须分属不同服务实例，哪怕同进程也要用不同端口或路由前缀隔离，否则 DTM 无法区分补偿目标
补偿失败不能静默跳过，必须进死信队列并告警
补偿接口本身可能失败：下游服务不可用、限流、熔断、超时。硬重试只会加剧雪崩，而跳过则等于放弃一致性。
- 补偿失败时，必须将 saga 实例状态设为
failed_compensation，把完整错误（如"http status 429"）写入last_error字段 - 同时写一条记录到
saga_dead_letter表，字段包括gid、step_name、error_message、retry_count，供人工干预 - 补偿逻辑本身要轻量：一条 SQL 或一次 HTTP 请求，超时设为 ≤3s，禁止在 Undo 里做远程调用链或复杂计算
- 别用 for 循环重试：应走独立 worker 拉取
compensation_task表，支持指数退避（retry_delay_sec）、最大重试次数（max_retry）和暂停/标记成功等人工入口
Saga 的复杂点不在编排逻辑，而在于每一步都得对抗网络不确定性：你得为每个 Do 设计幂等键，为每个 Undo 写状态校验，为每次状态更新加行锁，为每次补偿失败留人工兜底。漏掉其中任何一环，都不是“分布式事务”，只是个容易撕裂的业务流程。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
