go服务编排需手动实现saga协调器，封装幂等step接口并管理状态流转与补偿，依赖context控制超时与中断，而非框架自动完成。
Go 服务编排不能靠框架自动完成，得自己写协调器
Go 没有像 Java Spring Cloud 或 Node.js 的 Step Functions 那样的原生服务编排运行时。所谓“编排”，在 Go 里本质是手动控制多个服务调用的顺序、重试、超时和状态流转。你得自己实现一个 Coordinator 结构体，它持有各步骤的执行函数、回滚函数、超时配置和上下文传递逻辑。
常见错误是试图用 goroutine + channel 直接拼流程，结果状态丢失、错误无法统一捕获、回滚时机错乱。正确做法是把每步封装为带 Execute() 和 Compensate() 方法的接口：
type Step interface {
Execute(ctx context.Context, data map[string]interface{}) error
Compensate(ctx context.Context, data map[string]interface{}) error
}
- 每个
Step必须幂等，因为可能被多次执行或补偿 - 所有步骤共享同一个
map[string]interface{}作为数据上下文，避免跨服务传参混乱 - 协调器需记录当前执行到哪一步（例如用
stepIndex int），失败时从该步开始反向调用Compensate() - 不要在
Compensate()里抛新错误——它只应尽力恢复，失败也得吞掉或打日志，否则阻塞整个回滚链
Saga 模式必须显式管理事务边界和补偿触发条件
Go 里没有分布式事务中间件自动帮你挂起/提交，Saga 是纯业务逻辑契约：每个服务调用成功后，必须立刻触发下一步；任意一步失败，必须按逆序逐个调用补偿操作。关键不是“怎么写补偿函数”，而是“什么时候决定触发补偿”。
典型陷阱是把网络超时、503 错误当成可重试临时故障，却没区分是否已产生副作用。比如调用支付服务返回超时，但实际扣款已发生——此时再补偿退款，就变成双花。
- 所有参与 Saga 的服务接口必须提供「查询最终状态」能力，例如
GetPaymentStatus(orderID)，用于幂等确认 - 协调器在每步后应主动查状态，而非仅依赖响应码判断成功
- 补偿操作本身也要支持幂等，例如退款接口带
refundID去重，而不是仅靠订单号 - 避免在补偿中调用可能再次失败的第三方服务（如发邮件通知）；这类旁路动作应走异步队列，不纳入 Saga 主链
用 go.uber.org/cadence 或 temporal.io 能省力，但要接受额外运维成本
如果团队能接受引入外部服务，Cadence 和 Temporal 是目前 Go 生态最成熟的 Saga 编排方案。它们把流程定义为 Go 函数，运行时自动持久化状态、重试、超时、补偿调度。但代价是必须部署和维护一套高可用的 Temporal Server 集群。
本地开发时容易忽略的是 worker 注册与 workflow 名称的严格匹配：
// 必须和 server 端注册的 workflow name 完全一致
func MySagaWorkflow(ctx workflow.Context, input SagaInput) error {
// ...
}
workflow.Register(MySagaWorkflow, "MySagaWorkflow")
- Worker 进程启动后，必须先完成注册再接收任务，否则 server 会报
WorkflowTypeNotFound - Temporal 默认不保存历史事件超过 3 天，长期运行的 Saga（如跨天审批流）需调大
RetentionPeriodInDays - 本地调试别用
temporalite代替正式集群——它的内存模式不模拟真实网络分区行为，掩盖补偿失败场景
ctx.Done() 和 cancel() 是 Saga 中断和超时的唯一可靠信号
Go 的 context 不是装饰品。Saga 流程中任何一步卡住（比如下游服务假死），都必须靠 ctx 主动中断，否则整个编排协程永远 hang 住。
常见错误是只在 HTTP client 层设超时，却忽略数据库操作、消息发送、甚至补偿函数本身的执行时间。
- 每个
Step.Execute()和Step.Compensate()都应接收ctx并在开头检查ctx.Err() != nil - 用
context.WithTimeout(parentCtx, 30*time.Second)包裹单步调用，而不是给整个 Saga 设一个总超时 - 协调器自身要监听
ctx.Done()，一旦收到取消信号，立即停止后续步骤，并并发触发已执行步骤的补偿（注意加锁保护共享状态） - 别用
time.AfterFunc替代 context 超时——它无法感知上游取消，也无法跨 goroutine 传播
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
