time.AfterFunc用于可取消的延迟补偿，而非单纯等待；需显式传参、保存Timer以便Stop，补偿任务必须持久化到数据库防丢失。
用 time.AfterFunc 做单步延迟补偿，不是为了“等”，而是为了“可取消”
Saga 补偿本身是失败后立即触发的逆向操作，但某些场景下你不能立刻执行补偿——比如要等外部系统状态稳定、或避开高峰期、或需人工确认窗口。这时延迟不是业务逻辑，而是调度策略。直接写 time.Sleep 会卡死 goroutine，且无法响应订单取消、服务下线等信号。time.AfterFunc 是唯一轻量又可控的选择。
- 必须显式传参，别捕获循环变量：
for _, step := range steps { time.AfterFunc(delay, func(s SagaStep) { s.Undo() }(step)) } - 返回的
*time.Timer要存起来，后续可通过timer.Stop()中断——比如用户在补偿前完成了支付，整个 Saga 就该静默退出 - 函数体里别做无 recover 的 HTTP 调用；补偿失败要落库重试，而不是靠延时重入（那会叠加延迟）
延迟补偿任务必须持久化，否则重启就丢
本地内存里的 time.AfterFunc 在进程崩溃或滚动发布时全部失效。分布式任务要求“补偿不丢”，意味着延迟动作本身得先写入可靠存储。常见错误是：正向操作成功 → 触发 time.AfterFunc → 进程挂了 → 补偿永远不执行。
- 补偿任务生成时，立刻往数据库插入一条记录，字段至少含：
trace_id、step_name、due_at（时间戳）、status = 'pending' - 用独立 worker 定时扫描
WHERE status = 'pending' AND due_at ，查到就执行并 <code>UPDATE SET status = 'executed' - 不要依赖 Redis 的
ZSET + ZRANGEBYSCORE扫描做主链路——它不保证强一致，ZSET 中 score 相同的 member 顺序不可控，可能漏任务
多阶段补偿的延迟不能简单叠加，得按依赖关系编排
一个转账 Saga 可能包含：扣款 → 发通知 → 更新积分 → 同步风控。如果每步都设固定延迟（比如统一 30 秒），会导致通知还没发完，积分更新补偿就启动了，破坏因果性。
Golang Spf13 Viper
下载
Go 配置库，使用 spf13/viper — 分层优先级（flag > env >file > KV > default），提供 BindPFlag/BindPFlags、SetEnvPrefix + SetEnvKeyReplace 等功能。
- 补偿延迟应基于上一步的完成时间动态计算，例如：
compensateAt := lastStepFinishedAt.Add(1 * time.Minute) - 所有补偿任务共享同一个
trace_id，worker 扫描时按trace_id分组，确保同一笔事务的补偿串行执行（避免并发 undo 破坏幂等） - 若某步补偿失败，后续步骤的延迟起点不是原计划时间，而是失败重试成功的时间点——否则会出现“补偿还没开始，下一阶段补偿已过期”的错乱
Redis 延迟队列只适合“投递层”，别让它扛补偿逻辑
用 Redis ZSET 存延迟消息看似简单，但它只解决“什么时候把任务塞进执行队列”，不解决“补偿是否真的成功”。很多团队把补偿逻辑全塞进 Lua 脚本里，结果脚本超时、网络抖动、Lua 内存溢出，导致任务卡在 ZSET 里不动。
立即学习“go语言免费学习笔记（深入）”；
- Redis 只负责：接收补偿请求 → 记录
score = due_at→ 到期后LPUSH到执行队列（用 Lua 保证原子性） - 真正的补偿函数必须在 Go worker 里执行，带 context 超时、重试、日志、指标上报
- 别在 Lua 里调外部 HTTP；也别把数据库连接池、配置管理这些有状态的东西塞进 Redis 脚本里——它不该知道业务细节
补偿最容易被忽略的点是：它不是“一次性的后台任务”，而是主流程的延伸。延迟只是调度手段，状态持久化、执行可见性、失败兜底，三者缺一不可。任何把补偿当成“发个定时器就完事”的设计，在压测或发布时一定会暴露。
