Go中channel实现pipeline的核心是各stage仅关注自身输入输出，通过接收chan T、返回chan U来自然隔离错误、控制并发、复用stage；写错主因是手动塞数据而非让channel自动流动，且需避免中间close、正确处理panic与超时。
Go 里用 channel 实现 pipeline，核心是“每个 stage 只关心自己的输入输出”
不是靠全局状态或共享变量串联逻辑，而是让每个函数接收 chan T、返回 chan U。这样能自然隔离错误、控制并发、复用 stage。写错的关键在于：把 channel 当成“队列”来手动塞数据，而不是让它自己流动。
- 每个 stage 应该用
for range消费输入 channel，避免提前关闭或漏读 - 输出 channel 必须由 stage 自己创建并返回，不能复用上游的
- 如果某个 stage 可能 panic 或阻塞，必须加
recover或用select带超时，否则整条 pipeline 卡死 - 不要在 pipeline 中间用
close()—— 关闭应只发生在源头（如数据生成 stage）或明确终结处
为什么 range 在 channel 上会卡住？常见死锁场景
典型表现是程序 hang 住，goroutine profile 显示一堆 goroutine 停在 range 或 `range 等着永远等不到 io.EOF 类信号。
- 源头 stage 忘了
close(out)（比如生成完所有数据后没关输出 channel） - 中间 stage 提前 return 且没 close 输出 channel，下游
range一直等 - 用了带缓冲的 channel 但容量设太小，上游发满后阻塞，下游又因逻辑 bug 没及时收，形成双向等待
- 错误地用
len(ch) == 0判断“是否还有数据”——这不可靠，且和range语义冲突
select + default 在 pipeline stage 中怎么用才不丢数据？
想非阻塞处理、做 fallback 或限流时，容易误用 default 导致数据直接丢弃。关键原则：只要输入 channel 还开着，就不能丢任何值；default 只该用于“这次不处理，但下次还来得及”。
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 别在主循环里写
select { case v := —— 如果 <code>process()慢，default就会不断跳过新数据 - 正确做法是给处理加缓冲：用
out := make(chan Result, 1)，再在case out 分支里发结果，配合 <code>default做背压（比如打日志、降级） - 若真要丢数据，显式写
select { case ，而不是依赖 <code>default隐式丢 - 注意：
select中多个case同时就绪时是随机选，别假设顺序
性能陷阱：为什么加了 goroutine 反而更慢？
以为“每个 stage 起个 goroutine 就自动并发”，结果 CPU 利用率低、延迟更高。本质是 goroutine 创建/调度开销压过了计算收益，或者 channel 成了瓶颈。
立即学习“go语言免费学习笔记（深入）”；
- 纯 CPU 计算型 stage（比如字符串转换），起 goroutine 反而增加调度负担；应优先考虑批量处理 + 复用 goroutine
- channel 缓冲区设为 0（unbuffered）时，每次收发都需两端 goroutine 同时 ready，极易成为同步点；简单加缓冲（如
make(chan int, 64)）常能显著改善吞吐 - 多个 stage 共享同一个 input channel，但没加锁或同步机制，导致竞态 —— Go 的 channel 不是线程安全的“多读者”容器，一个 channel 只该被一个 goroutine 读
- 用
runtime.GOMAXPROCS(1)测试时 pipeline 表现异常，不代表生产环境有问题；真实瓶颈往往在 I/O 或 GC，而非 goroutine 数量
真正难的不是写出能跑的 pipeline，而是判断哪一级该并发、哪一级该批处理、哪一级该加缓冲 —— 这些没法靠模式套用，得看实际数据节奏和 stage 耗时分布。
