第二个阶段收不到数据，是因为第一阶段未关闭 out channel，导致 range 无限阻塞；需在第一阶段完成发送后调用 close(out)。
用 chan 串联多个阶段时，为什么第二个阶段收不到数据？
常见现象是：第一阶段往 out channel 发了数据，但第二阶段的 range 或 一直阻塞。根本原因通常是 channel 没有被关闭，或关闭时机不对。
Go 的 range 在 channel 关闭前不会退出，而多个 goroutine 并发写入时，谁来关、什么时候关，必须显式协调。
- 每个阶段只负责从输入 channel 读、向输出 channel 写；关闭输出 channel 的责任应由该阶段的启动者承担（通常是调用方或上一阶段）
- 若某阶段有多个 goroutine 同时向同一
outchannel 写，必须用sync.WaitGroup等待全部写完再关闭，否则可能漏数据或 panic - 别在 stage 函数里直接
close(in)—— 输入 channel 是上游给的，你没权限关
示例片段：
func gen(nums ...int) <-chan int {<br> out := make(chan int)<br> go func() {<br> defer close(out)<br> for _, n := range nums {<br> out <- n<br> }<br> }()<br> return out<br>}
多个 stage 之间要不要加 buffer channel？
加不加取决于吞吐压力和错误容忍度。无缓冲 channel 要求发送和接收严格同步，一旦某个 stage 处理变慢，整个 pipeline 就卡住。
立即学习“go语言免费学习笔记（深入）”；
Golang Spf13 Viper
下载
Go 配置库，使用 spf13/viper — 分层优先级（flag > env >file > KV > default），提供 BindPFlag/BindPFlags、SetEnvPrefix + SetEnvKeyReplace 等功能。
- 简单测试或 stage 耗时稳定 → 用
make(chan int)即可 - 下游偶尔延迟（如日志写磁盘、HTTP 请求）→ 建议设小 buffer，比如
make(chan int, 16)，避免上游频繁阻塞 - buffer 不是越大越好：内存占用上升，且可能掩盖背压问题，让失败延迟暴露
- 注意：buffer channel 无法通过
len(ch) == cap(ch)判断是否“满”，因为并发下长度瞬息变化，不能作为流控依据
怎么安全地终止正在运行的 pipeline？
直接杀 goroutine 不行，Go 没提供外部中断机制。正确做法是用 context.Context 驱动每个 stage 主动退出。
- 每个 stage 的 goroutine 都要监听
ctx.Done()，收到信号后清理资源、停止写入、尽快返回 - 不要在 stage 里直接
close(out)，除非你能确保所有写操作已结束；更稳妥的是让启动 pipeline 的主函数统一关闭最终输出 channel - 如果某 stage 内部调用了阻塞系统调用（如
http.Get），记得传入带 timeout 的ctx，否则它可能永远不响应 cancel
关键点：ctx.WithCancel 返回的 cancel 函数应在 pipeline 不再需要时调用，且只调一次。
为什么用 for range ch 而不是 for { ？
前者自动处理 channel 关闭，后者在 channel 关闭后会 panic：panic: send on closed channel 或无限读零值（对非指针类型）。
-
for range ch在 channel 关闭、数据读尽后自然退出循环，适合绝大多数 stage 场景 - 只有极少数情况需要手动控制读取节奏（比如想跳过某些值、或配合
select做超时），才用for { select { case v, ok := - 别忘了：channel 关闭后，
会立即返回零值 + <code>ok==false，但这不是 “退出循环” 的充分条件 —— 你得自己判断并 break
复杂点在于：pipeline 中每个 stage 的生命周期、关闭顺序、错误传播路径都得人工对齐。没人替你管这些，写错一环，整条链就静默卡死或 panic。
