Golang Pipeline取消机制：上游关闭下游退出

context.WithCancel 不能自动传播取消信号，因 Context 仅是信号载体，goroutine 必须主动检查 ctx.Done() 并退出；常见错误是 select 中遗漏 case <-ctx.Done()。

Go context.WithCancel 为什么不能自动传播到所有 goroutine

因为 context.Context 本身不带执行控制能力，它只是个信号载体；goroutine 是否响应取消，完全取决于你有没有在关键位置检查 ctx.Done() 并主动退出。

常见错误现象：select 里漏了 case <-ctx.Done()，或者只在函数开头检查一次、后续循环中不再轮询；结果上游已取消，下游 goroutine 还在疯狂跑数据、占内存、发请求。

• 必须在每个可能阻塞或耗时的操作前，插入 select 或 if ctx.Err() != nil 判断
• 尤其注意 for 循环内部——不能只在循环外 check 一次
• 如果用了 time.Sleep、http.Client.Do、chan recv/send，都要确保它们能被 ctx 中断（例如用 time.AfterFunc 替代裸 sleep，用 http.NewRequestWithContext）

Pipeline 阶段间 chan 要用带缓冲的还是无缓冲的

取决于阶段处理速度是否稳定、是否允许背压传递。无缓冲 chan 强制同步，天然支持“上游等下游就绪”，但容易卡死；带缓冲 chan 可缓解瞬时抖动，但会掩盖阻塞问题，甚至导致内存泄漏。

使用场景：当某个阶段偶尔慢（比如网络 IO 波动），用小缓冲（如 1–4）可避免 pipeline 整体停摆；但若下游长期积压，缓冲区填满后写操作会阻塞，此时必须靠 ctx.Done() 才能唤醒。

• 默认优先选无缓冲 chan int —— 行为可预测，取消信号能立刻反映在阻塞点上
• 加缓冲仅用于明确知道“下游延迟有界且短暂”，例如日志聚合阶段暂存几条记录
• 绝不要用 make(chan T, math.MaxInt) 或大缓冲（如 10000+），这等于放弃背压，取消可能永远不生效

下游 goroutine 退出时要不要 close 输出 chan

要，但只能由**唯一确定的发送方**关闭，否则 panic：send on closed channel。Pipeline 中，通常由当前阶段的主 goroutine（即启动 worker 的那个）负责 close 自己的输出 chan。

容易踩的坑：多个 goroutine 同时往一个 chan 发数据，又都试图 close 它；或者上游已 close 输入 chan，下游误以为该轮到自己 close 输出 chan，结果和别的 worker 冲突。

• 每个阶段定义自己的输出 chan，并由该阶段的启动函数（如 stage1(in <-chan int, ctx context.Context) <-chan int）在 defer 中 close
• worker goroutine 只管 send，不负责 close
• 接收方永远不要 close 收到的 chan —— 它不是你创建的

cancel 后如何确保所有 goroutine 真的退出了

没有银弹。Go 没有内置的 goroutine join 机制，得靠组合手段验证：等待 + 信号 + 有限超时。

性能影响：加等待逻辑本身会拖慢正常退出路径，所以只应在测试或关键清理阶段启用；生产代码中更依赖“正确检查 ctx”来保证终态，而非强等。

• 用 sync.WaitGroup 记录启动的 worker 数，在 cancel 后调用 wg.Wait()，配合 defer wg.Done()
• 每个 worker 在退出前向一个 done chan 发信号，主协程用 for i := 0; i < expected; i++ { <-done } 收集
• 务必设超时（如 time.After(5 * time.Second)），防止因漏检 ctx 导致永久 hang

最常被忽略的一点：子 goroutine 启动了新的 goroutine（比如日志上报、metric 上报），却没把 ctx 传下去，导致 cancel 后这些“孙辈”还在跑。Pipeline 的每一层，只要 spawn 新协程，就必须显式传递上下文。