Pipeline 数据卡住因 channel 同步阻塞，上游发送需下游接收；应由最下游关闭通道、各阶段启独立 goroutine，并用 struct{Value T; Err error} 传递错误与数据。
Go 里用 chan 拼 Pipeline，为什么数据会卡住？
因为管道链中任意一环没消费完、或提前关闭了 chan，上游就会阻塞在发送操作上。Go 的 channel 默认是同步的，send 必须等到有 goroutine 在另一端 recv 才能继续。
- 避免在中间环节用
close(ch)—— 只有最下游消费者才该决定何时结束；上游只管发，不关通道 - 每个阶段都应启动独立 goroutine，否则会串行执行，失去并发意义：
go stage(in) // 不要直接调 stage(in) - 如果某阶段可能跳过部分输入（比如过滤空值），记得用
for range in+select配合default或带超时的接收，防止死锁
怎么让 Pipeline 支持错误传播和提前终止？
原生 channel 不带错误信号，必须显式设计错误通道或封装结构体。常见做法是把 error 和业务数据一起传，或者额外开一个 chan error。
- 推荐统一返回
struct{ Value T; Err error }类型，下游用if v.Err != nil判断，比多开一个 error chan 更易追踪来源 - 若需快速中断整条链，可在每个 stage 入口加
select { case ，由上游控制 <code>donechannel 关闭 - 注意：不要在多个 goroutine 中重复关闭同一个
chan，会导致 panic：panic: close of closed channel
range 遍历 channel 时，为啥有些数据永远收不到？
因为 range ch 只在 channel 被关闭后才退出循环。如果上游没关 channel，下游就一直等着，哪怕所有数据都已发出。
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 只有明确知道上游会关 channel（且只关一次），才能放心用
for v := range ch - 更安全的做法是配合 context：
for { select { case v, ok := - 切记：
close()应由**唯一写入者**调用，常见错误是多个 goroutine 同时向同一 channel 发送并各自尝试关闭
Pipeline 性能差，是不是 channel 太重了？
不是 channel 本身重，而是滥用缓冲区或阻塞模型导致调度失衡。小数据量下无缓冲 channel 往往更快；大数据流才需要谨慎设缓冲大小。
立即学习“go语言免费学习笔记（深入）”；
- 缓冲区设太大（如
make(chan int, 1e6)）会吃内存，还掩盖背压问题，下游处理慢时上游照发不误，OOM 风险高 - 缓冲区设太小（如
1）又容易频繁阻塞，增加 goroutine 切换开销 - 真实场景建议从
0（无缓冲）起步，压测时观察runtime.ReadMemStats和 goroutine 数量变化，再按吞吐瓶颈微调
真正难的是状态协同——比如某个 stage 出错后，如何让前面还在跑的 goroutine 安全退出、资源释放干净。这部分没有银弹，得靠 context + done channel + 显式回收逻辑兜底。
