无缓冲channel在pipeline中易卡死，因其要求发送与接收必须同步就绪，任一stage处理延迟即导致上游阻塞、整条流水线死锁。
为什么无缓冲 channel 在 pipeline 里容易卡死
因为 Go 的 chan int 默认无缓冲，上游往 channel 发数据会**立刻阻塞**，直到下游从同一 channel 接收。一旦某个 stage 处理变慢（比如 HTTP 请求延迟、JSON 解析卡住），整个流水线就停在那儿——不是性能差，是直接 deadlocked。
常见错误现象：fatal error: all goroutines are asleep - deadlock，尤其出现在最后 stage 没启 goroutine、或中间 stage panic 后没 close 输出 channel 时。
- 每个 stage 必须用
go func() { ... }()启动独立 goroutine，不能同步调用 - 下游必须用
for v := range in或带ok判断的select消费，否则上游close()后仍会阻塞 - 永远不要在 stage 内部
close(in)——输入 channel 是上游给的，你没权限关
有界 channel 怎么设 buffer 才不翻车
用 make(chan int, N) 是正确方向，但 N 不是越大越好。buffer 太大 → 数据全堆在内存里，背压失效，OOM 风险高；太小或为 0 → 上游频繁阻塞，吞吐骤降。
真实场景中，buffer 应匹配「单阶段处理耗时波动」和「下游消费速度下限」。比如：日志清洗平均 1ms/条，偶发 10ms；下游稳定 5ms/条，则 buffer 至少预留 2~3 倍瞬时积压量（建议从 make(chan Item, 64) 起调）。
立即学习“go语言免费学习笔记（深入）”；
- IO 密集型 stage（如 HTTP 请求、DB 查询）：buffer = 1～16，避免堆积请求
- CPU 密集型 stage（如解密、正则匹配）：优先用无缓冲
make(chan int)，强制上游等待下游就绪，天然限速 - 绝不要对不确定长度的输入（如大文件逐行读）用超大 buffer，例如
make(chan string, 1000000) -
len(ch) == cap(ch)不能作为流控依据——并发下长度瞬息变化，不可靠
怎么让有界 channel 真正起到背压作用
buffer 只是缓冲区，不是背压开关。真正起作用的是：当 buffer 满时，上游发送操作会阻塞，从而倒逼上游减速或暂停生产——这要求上游也运行在 goroutine 中，并能响应阻塞。
如果上游是同步逻辑（比如一个 for 循环直接往 channel 写），它一阻塞就卡死主线程，整个 pipeline 还是瘫痪。所以必须确保：源头也是 goroutine 启动的，且能被下游 buffer 满的状态“推着走”。
- 源头函数（如
gen）内部必须用go func() { defer close(out); ... }() - 所有 stage 的输出 channel 都要配
defer close(out)，哪怕没写任何值（比如 filter 全部过滤掉） - 别依赖
len(ch)做判断——它不是原子操作，且无法反映真实阻塞状态 - 监控时看
runtime.ReadMemStats().HeapInuse增长趋势，比看 channel 长度更靠谱
错误传递时有界 channel 容易漏关或误关
加了 buffer 的 channel 在错误提前终止时，关闭时机更难把握：写入端可能还在往 buffer 里塞数据，你一关，未消费的数据就丢了；或者关得太晚，下游已退出，channel 泄漏。
正确做法是用 context.Context 统一驱动关闭，而不是靠“buffer 满了就关”。每个 stage 监听 ctx.Done()，收到信号后停止写入、等当前写完再 close(out)。
- 错误发生时，由主控 goroutine 调用
cancel()，而非某个 stage 自行close() - stage 内部用
select同时监听ctx.Done()和输入 channel，一收到 cancel 就 return - 别在 stage 里 recover panic 后继续发数据——buffer 里塞的是脏值，下游无法区分
- 如果要用
errChan chan error，约定只由第一个出错 stage 发一次，其他 stage 监听并立即 return
有界 channel 的核心价值不在“缓”，而在“控”——它把隐式的调度压力，变成显式的阻塞信号。但这个信号只有在上下游都按规则跑 goroutine、正确 close、合理响应 context 时，才能真正传导到位。随便加个 make(chan T, 100)，反而更容易掩盖问题。
