Saga模式需显式编写正向与补偿逻辑，确保幂等性与可逆性；Temporal中将补偿作为Activity注册，用context透传traceID，测试需模拟服务失败并验证重试机制。
Go 分布式工作流里，Saga 模式怎么用 Saga 库写补偿逻辑
Go 生态没有原生的分布式事务框架，Saga 是最贴近生产需求的落地模式。官方库如 go-saga（非标准名，实际常用 temporalio/temporal-go 或自建轻量 saga 状态机）并不直接提供“补偿事务”抽象，而是靠开发者显式编排正向步骤与对应补偿函数。关键不是找一个包自动帮你回滚，而是让每步操作都具备幂等性 + 可逆性。
实操建议：
-
Compensate()函数必须和Execute()接收相同参数（或能从上下文还原），否则补偿时拿不到原始订单 ID、金额等关键信息 - 不要在补偿函数里调用新服务——它本身就得是最终一致的终点。例如：支付服务已扣款，补偿就是调
Refund()；库存服务已扣减，补偿就是调RestoreStock() - 用
context.Context透传 traceID 和重试策略，避免补偿链路丢失可观测性
为什么不能依赖数据库本地事务跨服务回滚
因为每个微服务有自己的数据库，START TRANSACTION 只对单库生效。当你在订单服务执行 INSERT INTO orders，同时想让库存服务的 UPDATE inventory SET qty = qty - 1 也进同一个事务——这在 Go 的 sql.Tx 里根本做不到。
常见错误现象：
- 手动在代码里先调 A 服务再调 B 服务，发现 B 失败就“手动 rollback A”，但 A 的 HTTP 调用已发出去，网络超时或 A 侧异步落库后无法撤回
- 用
defer包一层“回滚函数”，结果 defer 在当前 goroutine 结束时才执行，而补偿需要在另一个服务、另一个进程里触发 - 把补偿逻辑写成同步阻塞调用，导致整个工作流卡在失败节点，吞吐归零
temporal-go 中如何注册可重试 + 可补偿的 Activity
Temporal 是目前 Go 生态最成熟的分布式工作流引擎，它的 Activity 天然支持失败重试与手动触发补偿（通过 workflow.ExecuteChildWorkflow 启动补偿子流程）。核心不是“自动补偿”，而是把补偿动作也当成一个正规 Activity 来注册和调度。
Go 配置库，使用 spf13/viper — 分层优先级（flag > env >file > KV > default），提供 BindPFlag/BindPFlags、SetEnvPrefix + SetEnvKeyReplace 等功能。
实操要点：
- 每个正向
Activity必须返回足够信息给 workflow logic，例如：{OrderID: "o-123", PaymentID: "p-456"}，后续补偿要用到这些 ID - 补偿
Activity函数名建议带Compensate前缀，如CompensateChargePayment，并在 workflow code 中显式调用：workflow.ExecuteActivity(ctx, CompensateChargePayment, input).Get(ctx, nil) - 设置
ActivityOptions的StartToCloseTimeout和RetryPolicy，否则补偿失败会静默丢弃——这是线上最常被忽略的一点
本地测试补偿逻辑时，怎么模拟服务临时不可用
真实环境里，补偿失败往往不是逻辑错，而是下游服务短暂 503 或网络抖动。本地跑单元测试不能只 mock 成功路径。
推荐做法：
- 用
gomock或接口注入，在测试中让某个ChargePayment实现随机返回err，验证 workflow 是否按预期触发CompensateChargePayment - 在补偿
Activity里加time.Sleep(10 * time.Second)，再配一个短超时（如StartToCloseTimeout: 5 * time.Second），看是否触发重试而不是直接失败 - 不要用
t.Fatal断言补偿必须成功——它应该被设计为“最终成功”，测试只需确认补偿任务被发出、参数正确、重试机制启用
真正难的从来不是写几个 CompensateXxx 函数，而是确保每个服务的正向操作都满足幂等、每个补偿操作都具备前序状态可还原能力、以及整个流程在部分节点宕机数小时后仍能靠重试+持久化进度恢复。这些没法靠一个库自动解决，得一行行代码对齐业务语义。
