Go pipeline需用goroutine+channel实现并发数据流，核心难点在于channel关闭时机、缓冲策略和错误传播；直接链式调用因缺少goroutine导致死锁，无缓冲channel要求收发双方同时就绪，关闭out须在所有发送路径结束后统一执行，缓冲仅用于上线后明确速率匹配场景，错误与中断需通过select+context+单error channel协同处理。
Go 的 pipeline 不是函数链式调用，而是靠 goroutine + channel 构建的并发数据流；写错最常卡死或漏数据，核心问题在 channel 关闭时机、缓冲策略和错误传播三处。
为什么直接 chain 调用会 fatal error: all goroutines are asleep - deadlock
新手常把 square(gen(2,3)) 当作 pipeline，但这是同步调用：上游 gen 往 channel 写，下游 square 还没启动 goroutine 去读，channel 阻塞，整个流程挂住。
- 每个 stage 必须显式启动 goroutine，不能依赖调用方顺序执行
-
gen返回的是，但若下游没用go启动消费者，它就只是个“没人监听的发射器” - 无缓冲 channel 要求“发送方和接收方同时就绪”，缺一不可
怎么正确关闭 channel 才不 panic 或漏数据
defer close(out) 放在 stage goroutine 里看似合理，但极易出错：如果上游提前关闭输入，stage 提前 return，defer 还是会执行，导致下游 range 立刻退出，而上游可能还在往已关闭的 out 写 —— panic 就在这儿。
- 关闭
out的时机必须是：所有有效数据发完 + 确认不会再发（包括 error path 和ctx.Done()分支） - 不要在 stage 函数体里
close(out)，而要在 goroutine 内部、所有out 路径之后统一关 - 下游用
for v := range in安全读取，但前提是上游真关了；别自己关输入 channel - panic 恢复后不能继续往
out发数据，否则下游拿到的是脏值
要不要加缓冲 channel？加多大才安全
加 make(chan int, 100) 能缓解短时抖动，但会掩盖背压缺失——上游猛灌、下游慢吞，内存悄悄涨到 OOM 才暴露问题。
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 开发调试阶段一律用无缓冲 channel（
make(chan int)），让阻塞立刻显现，倒逼你理清数据流节奏 - 上线后加缓冲，只在明确知道上下游速率匹配、且延迟敏感（如实时日志采样）时才考虑
- 缓冲大小不是越大越好：
len(ch)不反映写入状态，设成 10000 只会让 OOM 提前，而不是逻辑更健壮 - 有界缓冲 ≠ 背压控制：真正的背压靠下游消费速度反向约束上游，不是靠 buffer 吞掉压力
如何让 pipeline 支持中断和错误传递
原生 channel 没错误语义，context.Context 也不能只包一层就完事。常见错误是 select 里只检查 ctx.Done() 开头，但 或 out 仍可能永久阻塞。
- 所有 channel 操作必须套
select，包含ctx.Done()和in/out分支 - 错误传递推荐单 error channel：由首个出错 stage 发送一次
errCh ，其他 stage 监听并立即 return - 扇入（fan-in）合并多路时，必须等所有输入 channel 关闭才关输出 channel，不能靠计数——因为某路可能提前 close
- 别用
recover拦 panic 后续发数据，这会让下游无法区分正常零值和异常终止
真正难的不是写几个 stage，而是每条 channel 的生命周期谁管、何时关、关早了还是关晚了、buffer 是掩耳盗铃还是必要缓冲——这些细节没对齐，pipeline 表面跑通，实则随时崩在生产环境。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
