for range ch 是唯一安全的读取方式，因为它自动处理通道关闭、读取缓冲值并退出，避免死锁；而手动 for { v, ok :=
Go 里实现可靠的数据管道（pipeline），核心不是“怎么连 channel”，而是“怎么让每个环节不卡、不漏、不死”。绝大多数失败都源于对 for range ch 的误用、关闭时机错乱，或共用 channel 导致类型/生命周期混乱。
为什么 for range ch 是唯一安全的读取方式
手动写 for { v, ok := 看似灵活，实则极易出错：一旦上游提前关闭 channel，而你又在 <code>select 中混用了其他 case（比如超时或退出信号），ok == false 可能被忽略，goroutine 就卡在下一次接收上，永不退出。
-
for range ch在 channel 关闭且所有已发送值被读完后自动退出，语义明确、无遗漏 - 它隐式处理了
ok判断，避免手抖漏掉清理逻辑 - 若某 stage 需要提前终止（如遇到错误），必须显式
close(out)并 return，不能只 break 循环
每个 stage 必须有独立的输入/输出 channel
把所有步骤塞进同一个 chan interface{} 或反复复用一个 chan int，短期能跑，长期必崩。类型混杂会让编译器失去检查能力；生命周期不同步会导致下游 range 永远等不到 close；缓冲区设置也无法按需调整。
- 定义 stage 函数时，输入/输出 channel 类型要严格区分，例如：
func filter(in - 中间 stage 输出 channel 的缓冲大小应按实际吞吐设（如批量写 DB 用
make(chan []byte, 128)，实时告警用无缓冲） - 别在 stage 内部直接返回
make(chan T)—— 若上游没启动，这个 channel 就永远没人往里写，调用方会死锁
关闭 channel 的时机比你想的更苛刻
上游关 channel 不是“发完最后一个值就 close”，而是必须确认：所有已发送值已被下游完整消费，且下游 goroutine 已退出或进入 for range 的退出路径。否则就会出现 panic: send on closed channel 或下游漏数据。
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
立即学习“go语言免费学习笔记（深入）”；
- 只有生产者（最上游）有权 close 输入 channel；中间 stage 只负责 close 自己的输出 channel
- 若 stage 会过滤掉部分数据（如丢弃空行），它的输出 channel 收到的值数量 for range 永远阻塞
- 多个并行 worker 共享同一输入 channel 时，要用
sync.WaitGroup或errgroup.Group确保全部 worker 处理完才 close 输出 channel
别忽略 goroutine 泄漏和内存堆积
管道跑着跑着 CPU 100%、goroutine 数持续上涨、内存只增不减？八成是某个 stage 启动了 goroutine 却没退出机制，或者用了 io.Pipe 但 reader/writer 有一端没 Close。
- 所有启动 goroutine 的 stage，必须有明确的退出路径（通过 channel 关闭、context.Done() 或 error 返回）
- 用
io.Pipe时，writer 和 reader 任一端 panic 或提前 return，另一端若还在 Read/Write 就会永久阻塞 —— 必须配对 deferpr.Close()和pw.Close() - 日志、监控类 side-effect 操作（如
io.TeeReader）本身不阻塞，但目标 writer（如文件、网络连接）若失败未处理，可能让整个管道 hang 住
真正难的从来不是写出能跑的 pipeline，而是让每个 stage 在异常、中断、部分失败时仍能 clean up —— 这要求你对每个 close、每个 range、每个 goroutine 的生命周期，都有确定的掌控。
