直接用 channel 链接多个 goroutine 容易卡死，因未妥善处理关闭时机与接收端退出逻辑：range 未关闭的 chan 会永久阻塞，或生产者提前退出导致消费者空等；关键在于明确谁关、何时关、下游如何感知，需每阶段只读上游 in、只写下游 out，写操作配 defer close(out)，并用 for v := range in。
为什么直接用 channel 链接多个 goroutine 容易卡死
因为没处理好 channel 的关闭时机和接收端的退出逻辑。常见现象是某个阶段 range 一个未关闭的 chan，永远阻塞；或者生产者提前退出，但消费者还在等新数据。
关键不是“能不能连”，而是“谁负责关、什么时候关、下游怎么感知”。pipeline 的可靠性取决于关闭信号的传递是否完整。
- 每个阶段只从上游
in读、向下游out写，不碰其他 channel - 所有写操作必须配
defer close(out)（除非明确不关） - 用
for v := range in而不是for { select { case v := ，避免漏关 - 如果某阶段可能跳过某些输入（如 filter），仍要确保
out最终被关闭——哪怕没写任何值
如何让中间阶段支持取消和超时
单纯靠 channel 关闭不够，比如一个阶段正在调外部 HTTP 接口，上游已关闭 in，但它还在等响应。这时需要显式传入 context.Context。
注意：不能只把 ctx 传给 goroutine 启动函数，还要在每个阻塞点（http.Do、time.Sleep、甚至 select 等待 channel）中使用它。
立即学习“go语言免费学习笔记（深入）”；
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 每个阶段函数签名建议为
func(ctx context.Context, in - 在
for v := range in循环内，用select同时监听ctx.Done()和业务逻辑 - 一旦
ctx.Err() != nil，立即return，并依赖 defer 关闭输出 channel - 别在 pipeline 中启动带无限重试的子 goroutine，否则 cancel 会失效
buffered channel 该设多大？为什么设错会导致内存暴涨
设太大，数据全堆在 buffer 里，背压失效，OOM 风险高；设太小或不设（unbuffered），容易让上游 goroutine 频繁阻塞，吞吐骤降。
真实场景中，buffer 大小应匹配「单阶段处理耗时波动」和「下游消费速度下限」。比如日志清洗阶段平均 1ms/条，但偶尔达 10ms，下游稳定 5ms/条，那 buffer 至少预留 2~3 倍瞬时积压量。
- 初始调试建议用
make(chan T, 64)，上线后根据len(ch)监控值调整 - 绝不要对不确定长度的输入（如文件行流）用无界 buffer，例如
make(chan string, 1000000) - 如果阶段间耗时差异极大（如 IO 密集 vs CPU 密集），优先拆成独立服务，而非靠加大 buffer 强撑
- 用
runtime.ReadMemStats对比不同 buffer 下的HeapInuse增长趋势
怎么调试 pipeline 卡在哪一环
不能只看最终输出停了，得定位是哪段 channel 堵住、哪个 goroutine 挂起。Go 自带的 pprof 是最直接的方式，但得知道查什么。
核心思路：看 goroutine 栈是否卡在 channel 操作上，再结合 channel 当前长度和状态判断。
- 加
_ "net/http/pprof"，访问/debug/pprof/goroutine?debug=2查阻塞点 - 搜索关键词：
chan send（发不出去）、chan receive（收不到）、select（卡在多路等待） - 用
reflect.ValueOf(ch).Len()和.Cap()打印各 stage channel 实时积压量（仅调试用） - 避免在生产环境用
log.Printf打满每个阶段的输入/输出——IO 开销会掩盖真实瓶颈
defer close(out) 和 select { case 的组合里，少一个，整条链就可能静默卡住。 
