人工审批节点必须用事件驱动+外部信号恢复，禁用轮询或sleep：否则DB压力大、延迟高、扩缩容状态丢失、并发下重复执行。正确方案是sync.Cond本地等待/唤醒，生产环境结合Redis Pub/Sub跨实例广播，恢复前查DB加锁校验状态，确保幂等与上下文一致。
人工审批节点不能靠轮询或 sleep 等待，必须用事件驱动 + 外部信号恢复。 否则 CPU 白耗、延迟高、扩缩容后状态丢失，线上一压就崩。
为什么 wait_for_approval 不能用 time.Sleep 或定时任务轮询
常见错误是写个 goroutine 循环查数据库字段 status == "pending"，每秒跑一次。这在单机 demo 里能跑通，但真实场景下问题集中爆发：
- 每 1 秒查一次 DB，1000 个待审流程就是 1000 QPS，DB 直接打满
- 审批人点“通过”到流程继续，平均延迟 500ms（轮询间隔一半），用户感知卡顿
- K8s 滚动更新时旧 Pod 被杀，正在轮询的 goroutine 全丢，流程永久挂起
- 没有事务隔离：两个协程同时查到 pending，都去执行后续节点，造成重复扣款、双发通知
正确做法：用 sync.Cond + 唯一 instanceID 实现本地等待/唤醒
适用于单实例部署、或配合 Redis 分布式锁降级的轻量场景。核心是把「等待审批」变成「等待某个 instanceID 对应的条件成立」：
- 审批开始前：
cond.L.Lock()→ 写入approval_status[instanceID] = "pending"→cond.L.Unlock() - 等待协程：
cond.L.Lock()→for approval_status[instanceID] != "approved" && approval_status[instanceID] != "rejected" { cond.Wait() }→cond.L.Unlock() - 审批回调（如 HTTP API）：
cond.L.Lock()→ 更新approval_status[instanceID]→cond.Signal()→cond.L.Unlock()
注意：cond.Wait() 必须放在 for 循环里防虚假唤醒；approval_status 是 map[string]string，需用 sync.RWMutex 保护读多写少场景。
立即学习“go语言免费学习笔记（深入）”；
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
生产环境必须支持跨进程唤醒：用 Redis Pub/Sub 或消息队列
单机 sync.Cond 在多实例下失效。真实系统中，审批动作来自钉钉/飞书/OA，回调请求可能打到任意后端实例：
- 所有实例订阅同一个 Redis channel，例如
workflow:resume:{instanceID} - 审批回调收到后，
redis.Publish("workflow:resume:ins_abc123", "approved") - 每个实例起一个 goroutine 监听该 channel，收到消息后调用
cond.Signal()或直接触发后续节点 - 为防消息丢失，Redis channel 需设
EXPIRE 300，且监听 goroutine 要处理连接断开重连
别用 redis.BLPOP：它会消费消息，多个实例竞争导致唤醒丢失；PUB/SUB 是广播，天然适合多实例。
外部信号怎么和流程引擎对接不漏不重
信号本身只是通知，关键在「收到信号后，如何安全恢复指定 instanceID 的流程」：
- 恢复前先查 DB：
SELECT status, current_node FROM workflow_instances WHERE id = ? FOR UPDATE，确保状态未被其他操作修改 - 只允许从
"pending_approval"状态迁出，若已是"processed"，直接忽略信号（幂等） - 更新 DB 后，再调用调度器
scheduler.Resume(context.Background(), instanceID)，而不是直接执行节点函数 - 信号处理函数里禁止做耗时操作（如发邮件、调外部 API），这些应交给后续节点异步完成
最易被忽略的一点：信号恢复必须走和原始流程相同的 context 路径——比如原流程用了 context.WithTimeout(parent, 24*time.Hour)，恢复后不能新建 context，否则超时逻辑错乱，人工审批三天后流程自动失败就成玄学问题。
