Pipeline卡死因同步链式调用导致阻塞，正确做法是各stage启用独立goroutine、分离输入输出chan、慎用缓冲区，并集成context实现中断传播与背压控制。
为什么 chan 直接连写会卡死
Go 的 pipeline 本质是靠 chan 串起多个 stage，但新手常把多个 goroutine 用同步方式“链式调用”，结果第一个 stage 写满缓冲区、第二个没读，整个流程就挂住。
根本原因是：pipeline 不是函数调用链，而是并发数据流，每个 stage 必须独立运行、异步推进。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 每个 stage 都要启动独立
goroutine，不能在主线程里顺序调用stage1()→stage2() - 输入
chan和输出chan要显式分离，避免复用导致阻塞蔓延 - 缓冲区大小不是越大越好——
make(chan int, 1000)看似安全，实则掩盖背压问题，调试时建议先用0（无缓冲）暴露阻塞点
context.Context 怎么插进 pipeline 中断传播
没有 context 的 pipeline 无法响应超时或取消，比如下游 stage 处理慢，上游还在拼命发数据，内存涨到 OOM 才发现不对劲。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 每个 stage 函数签名都带
ctx context.Context参数，且所有chan操作都要配合select+ctx.Done() - 别只在 goroutine 开头检查
ctx.Err()—— 读写chan时可能永久阻塞，必须用select包裹 - 下游 stage 关闭输出
chan前，记得调用close()；但上游绝不能依赖 “读到零值=结束”，要用ok判断通道是否已关闭
示例关键片段：
for {
select {
case <-ctx.Done():
return
case item, ok := <-in:
if !ok {
return
}
out <- transform(item)
}
}
怎么让 pipeline 支持扇入（fan-in）和扇出（fan-out）
单路 pipeline 只能线性处理，真实场景常要并行加速（如 4 个 worker 同时处理日志）或聚合多源（如合并 API、DB、缓存三路结果），这就得手动拼接 chan，而不是靠语言内置语法。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 扇出：用一个
for循环启动多个 goroutine，共用同一个输入chan，各自写入独立输出chan - 扇入：用单独 goroutine 从多个输入
chan中select读取，统一写入一个输出chan；注意别漏掉default或ctx.Done()分支，否则可能饿死 - 不要试图用
reflect.Select动态合并任意数量 channel —— 可读性差、难调试，固定几路就硬写几个case
为什么 defer close(out) 在 pipeline 里大概率是错的
很多人习惯在 stage 函数末尾写 defer close(out)，以为“函数退出就该关通道”。但 pipeline 中 stage 是长期运行的 goroutine，提前关闭 out 会导致下游立刻收到零值并退出，而上游可能还在往已关闭的 out 写数据，触发 panic：send on closed channel。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 关闭输出
chan的责任必须由该 stage 自己承担，且只能在确认“不会再有新数据写出”时才关 —— 通常是读完全部输入、且所有处理完成之后 - 如果输入
chan是无缓冲的，别在range in结束后立刻close(out)，因为range退出只代表输入被关了，不等于你已处理完最后一条 - 更稳妥的做法：用
sync.WaitGroup或atomic计数，等所有待处理项真正落库/发送/转换完毕，再关out
pipeline 的难点不在语法，而在对并发生命周期的精确控制——哪条 channel 由谁关、何时关、关了之后其他 goroutine 怎么感知，这些细节一错，整条链就静默失效，还很难复现。
