goroutine 泄漏常出现在 pipeline 的中间 stage 启动 goroutine 往下游发数据、上游因错误关闭输入 channel、下游未收到关闭信号等环节。
goroutine 泄漏常出现在 pipeline 的哪几个环节
pipeline 里最易漏掉的是未消费完的 chan，尤其在早期退出或错误提前返回时。比如一个中间 stage 启动了 goroutine 往下游发数据，但上游因错误关闭了输入 channel，下游却没收到关闭信号，goroutine 就卡在 ch 上永远阻塞。
常见错误现象：fatal error: all goroutines are asleep - deadlock 或程序内存持续上涨、pprof 显示大量 goroutine 停在 send/recv 操作上。
- 所有输出 channel 必须配对使用
close()，且只由写入方关闭；读取方用range或for v, ok := - 用
select+default做非阻塞发送，或加超时（select { case ch ），避免死等 - 用
context.WithCancel控制整条 pipeline 生命周期，每个 stage 都监听ctx.Done()并及时退出
buffered channel 大小设多少才不拖慢 pipeline
缓冲区不是越大越好。过大的 chan int（比如 10000）会让上游猛灌数据，下游处理不过来时，内存先爆了；太小（比如 1）又让 goroutine 频繁切换，调度开销明显。
实际应按「单次处理耗时 × 预期吞吐」粗估：如果下游单条处理平均 1ms，目标吞吐 10k QPS，那缓冲区撑住 10~50 条比较稳；IO 密集型可稍大，CPU 密集型建议 ≤ 8。
立即学习“go语言免费学习笔记（深入）”；
- 优先用无缓冲 channel（
make(chan T)）做强同步点，比如扇入（fan-in）前最后一级校验 - 扇出（fan-out）后每个 worker 用小缓冲（
make(chan T, 4)）缓解瞬时抖动 - 避免在 pipeline 中段用大缓冲 channel 替代背压控制——这只会掩盖问题，不会提升吞吐
如何让多个 stage 共享 context 而不互相干扰
直接把同一个 ctx 传给所有 stage 看似省事，但一旦某个 stage 主动调用 cancel()，整条链就断了。正确做法是每个 stage 从父 context 派生自己的子 context。
典型错误：在 for-select 循环里反复调用 context.WithTimeout(ctx, time.Second)，结果每次新建 timer，泄漏 timer goroutine。
- 用
ctx, cancel := context.WithCancel(parentCtx)创建子 ctx，仅在该 stage 退出时调一次cancel() - 需要超时控制时，统一在 pipeline 入口用
context.WithTimeout，各 stage 只读ctx.Done()，不重复套娃 - 若某 stage 需要独立重试逻辑，用
context.WithValue传 retry count，别用新 context 替换主链路 ctx
map/reduce 类 pipeline 怎么避免中间结果堆积
像 stage1 → stage2 → stage3 这种线性链，如果 stage2 是 map（并发转换），stage3 是 reduce（聚合统计），stage2 输出没节制，stage3 消费慢，stage2 → stage3 的 channel 就成内存黑洞。
根本解法不是调大 buffer，而是让 stage2 主动感知 stage3 的消费能力。Go 标准库没提供 backpressure 原语，得自己做信号联动。
- stage3 启动时预分配固定大小的“令牌 channel”（
make(chan struct{}, N)），每准备就绪就放一个struct{}{} - stage2 发送前先
，发完立刻归还（用 defer 或显式 send），实现“发一条、拿一令牌” - stage3 处理完一条就往
tokenCh写回，天然限流且零内存堆积
这个模式在日志采样、批量写入、流式压缩等场景很实用，但容易被忽略的一点是：token channel 容量必须小于 stage3 单次处理的最大并行数，否则还是压垮下游。
