stage函数必须显式close(out)而非defer，因defer在函数返回时才执行，若提前panic或context取消，上游可能仍在发送导致“send on closed channel”；正确做法是所有退出路径统一关闭out且关闭前停止写入。
为什么 stage 函数必须显式 close(out) 而不是靠 defer 自动关
因为 defer close(out) 在函数返回时才执行，但若 stage 内部提前 panic 或被 context.Context 取消，defer 仍会运行——可此时上游可能还在往 out 发数据，导致 “send on closed channel” panic。
正确做法是：所有退出路径（正常结束、error return、panic 恢复后）都确保 out 已关闭，且关闭前不再写入。常见模式是用 for 循环 + select 监听 ctx.Done()，并在循环外统一 close(out)。
- 不要在
for range in循环体内直接close(out)—— 会漏掉最后一批数据 - 若 stage 做 filter（可能跳过某些输入），不能只靠
range in结束来触发close，要单独计数或用标志位判断是否“处理完毕” - 用
recover()捕获 panic 后，必须立即close(out)并 return，否则 goroutine 继续空转
如何避免清洗 pipeline 中的 goroutine 泄漏
泄漏常发生在三类 channel 使用错误上：向已关闭的 out 持续发送、从无发送者的 in 无限接收、超时控制缺失导致 select 卡死。
真实场景中，一个未加 context 控制的 cleanStage2 若因下游 DB 写入超时卡住，它持有的 in channel 一直没被消费完，整个 goroutine 就挂起不退。
立即学习“go语言免费学习笔记（深入）”；
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 每个 stage 启动时必须传入
ctx context.Context，并在for循环中select监听ctx.Done() - 对 IO 密集型清洗（如调外部 API），用
time.After配合selectdefault 分支做非阻塞兜底，避免永久等待 - 禁止裸写
out ；改用带超时的封装，例如 <code>sendWithTimeout(out, x, 5*time.Second)
要不要给 channel 加缓冲？看清洗阶段的耗时波动
无缓冲 channel 强制同步，能暴露背压问题；但生产环境里，清洗耗时不均是常态，硬扛容易卡死整条流水线。
IO 密集型阶段（比如校验手机号、查维表）响应时间波动大，不加缓冲会导致上游频繁阻塞；CPU 密集型（如 JSON 解析、正则替换）则更看重调度效率。
- IO 密集型 stage：建议
make(chan T, 100)，缓冲大小根据 P99 延迟和并发 worker 数反推 - CPU 密集型 stage：缓冲设为
runtime.NumCPU() * 2到*4，减少 goroutine 切换开销 - 扇出（fan-out）worker 池：输出 channel 必须有缓冲，否则一个 worker 卡住就拖垮全部
错误怎么传？别用全局变量或 panic 跨 goroutine 传播
pipeline 是多 goroutine 协作结构，panic 不会自动跨 goroutine 传递，recover 也只对本 goroutine 有效。靠日志打点或全局 error 变量，根本无法让上游感知失败并中断。
生产级做法是每个 stage 配一个 errCh chan，主流程用 <code>select 等待首个错误或全部完成。关键是要保证错误通道本身不阻塞、不泄漏。
- 错误 channel 建议带缓冲：
errCh := make(chan error, 1)，防单个 stage 错误来不及读就 panic - stage 内发生错误时，先
sendNonBlocking(errCh, err)，再close(out)并 return - 主流程不能只等
range out结束，必须同时select监听errCh，收到错误立刻cancel()全局 context
实际跑通一条清洗 pipeline，最难的从来不是写逻辑，而是让每个 stage 的生命周期与 channel 状态严格对齐——关早了丢数据，关晚了卡死，不关就泄漏。这些边界条件，在本地小数据测试时全然不显，一到线上千 QPS 就立刻暴露。
