go中saga必须严格串行执行，禁用goroutine+channel编排，因其无法保证步骤依赖、超时控制与状态一致性，易导致补偿错乱或数据撕裂。
Go 里没有并发事务补偿机制——Saga 不是并发模型，而是状态编排模型；所谓“并发”只是错觉，真实执行必须严格顺序、可中断、可回滚。
为什么不能用 goroutine + channel 编排 Saga 步骤
看到“并发”就起 goroutine、塞 channel，是 Go 开发者最常踩的坑。Saga 的每一步都依赖前序步骤的结果（比如支付成功后才扣库存），而 goroutine 启动后无法取消，channel 收发也不带超时和重试语义。
- goroutine 一旦启动，就脱离父 context 控制；
context.WithTimeout()对它无效 - 用
select { case 做超时，无法区分“调用已发出但没响应”和“根本没发出去”，导致补偿误判 - channel 发送补偿信号？没人保证接收方在运行，也没人保证消息不丢——这等于把一致性押在运气上
- 真实场景中，Saga 实例可能跨进程恢复（如服务重启），内存里的 channel 和 goroutine 全部丢失
如何让 Saga 步骤真正可中断、可补偿
关键不是“怎么快”，而是“怎么稳”。每步执行前必须落库标记“即将执行”，成功后立即更新为“已完成”，失败或超时时查状态表，按逆序触发对应 Compensate() 函数。
- 每步正向操作（如
ChargePayment()）和补偿操作（如RefundPayment()）必须接受相同参数结构，确保补偿能还原原始上下文 - 不要在
defer里写补偿逻辑——defer只在函数退出时触发，而网络超时、HTTP 400 等“软失败”不会触发它 - 每个步骤的 HTTP 客户端 timeout 必须短于整个 Saga 的总 timeout，避免某一步拖死全局
- 状态必须持久化：至少存
saga_id、current_step、status（pending/compensating/finished）、data（JSON，含 OrderID、PaymentID 等）
Temporal 中 Activity 补偿怎么注册才可靠
Temporal 是目前 Go 生态最成熟的分布式工作流引擎，但它不自动补偿——你得把补偿动作也当成一个正规 Activity 来注册和调度。
- 正向
Activity（如ChargePayment()）必须返回足够信息（如{OrderID: "o-123", PaymentID: "p-456"}），供后续补偿使用 - 补偿
Activity函数名建议带Compensate前缀（如CompensateChargePayment），并在 workflow code 中显式调用：workflow.ExecuteActivity(ctx, CompensateChargePayment, input).Get(ctx, nil) - 必须设置
ActivityOptions的StartToCloseTimeout和RetryPolicy，否则补偿失败会静默丢弃——这是线上最常被忽略的一点 - 用
context.Context透传traceID，避免补偿链路丢失可观测性；别把 traceID 存在局部变量里
补偿失败后怎么避免卡死或双花
补偿本身可能失败：库存服务宕机、支付平台限流、余额不足……这时候 Saga 不能停，也不能无限重试。
- 补偿失败时，必须把实例状态设为
failed_compensation，并把失败原因（如"inventory service unreachable"）写进error_message字段 - 同时发告警到钉钉/企业微信——别试图自动降级或跳过补偿，那等于放弃一致性
- 补偿接口必须解析响应体里的
result_code，区分“业务拒绝”（如“订单已退款”）和“网络失败”（如http.ErrHandlerTimeout） - 重试次数建议设为 3～5 次，间隔指数退避；超过阈值后转入人工干预队列，而不是继续轮询
Saga 的复杂点不在代码量，而在状态迁移的确定性——每一步“做什么”“什么时候做”“失败了谁来兜底”，都得在数据库里留痕、在日志里可追溯、在监控里可告警。写完 Compensate() 函数不等于完成，得验证它在服务重启、网络分区、重复触发下是否依然幂等、可重试、不丢状态。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
