go语言中for range语法不支持直接遍历未声明的变量或无效表达式，s := range in语法错误，正确写法需先定义可遍历的切片、数组、map等。
为什么不能直接用 for range in 就完事
看似最简的写法：for s := range in { out ，实际一跑就卡死或 panic。原因不是语法错，而是语义陷阱：上游没 <code>close(in)，这个 range 就永远等下去；哪怕上游关了，下游如果没读完所有值，out 可能还在写，而你没做任何保护。
- 所有 stage 必须在自己的 goroutine 里运行，否则调用方会被阻塞
- 每个 stage 的
outchannel 必须显式close(out)，且只能在for range in循环结束后 —— 不能提前，也不能漏掉（包括 panic 路径） - 别信“上游关了我就安全了”：下游可能还没启动、或启动慢了，
range没开始，上游就关了，send on closed channel立刻 panic
make(chan T, N) 缓冲大小怎么选才不爆内存
缓冲不是越大越好，也不是越小越“流式”。它本质是背压缓冲区，设错会直接导致 OOM 或吞吐崩塌。
- 纯转换类 stage（如
ToUpper、JSONParse）建议用无缓冲：make(chan string)—— 强制上下游节奏对齐，避免上游猛灌 - 批量 IO 类 stage（如写 DB、发 HTTP）必须带缓冲，但大小要匹配实际批次：比如每次批量写 100 条，那就
make(chan []byte, 100)，别设成 10000 - 过滤型 stage（如丢弃空行）输出量不确定，缓冲宁小勿大；若担心丢数据，改用
select { case out 非阻塞发送 + 记录丢弃数
多个 stage 怎么串起来又不泄漏 goroutine
常见错误是每个 stage 自己开 goroutine，但没配退出机制。跑几分钟后 go tool pprof 一看几百个 goroutine 堆着不动，全是卡在 ch 或 <code>range ch 上。
- 串链时，只在最外层启动 goroutine：
go stage1(...)、go stage2(...)，不要在 stage 函数内部再go func() { ... }() - 每个 stage 必须响应
context.Context：把ctx.Done()加进select，收到 cancel 就清理并退出 - 如果用了
errgroup.Group并行跑多个 worker 共享同一输入 channel，必须等eg.Wait()完再close(out)，否则下游range会漏数据
什么时候该放弃 channel 管道，改用函数组合
不是所有“链式处理”都适合 channel。channel 是为并发、流式、异构类型设计的；如果你只是对几行字符串做 Trim→Split→Filter，用 channel 反而重且难测。
- 数据量小（f3(f2(f1(input)))
- stage 之间类型一致（都是
string或都是[]byte），且无需背压控制 → 用io.Pipe更轻，但注意它不处理 close 同步，reader/writer 任一端没 Close 就卡死 - 需要调试单步、打日志、mock 某个 stage → 函数式链天然支持，channel 管道得额外加日志 channel 或 wrapper
真正难的不是写出五级管道，而是让每一级在 panic、超时、上游断连、下游卡住时，都能干净退出、不泄漏、不 panic、不丢数据。这些边界条件往往只在压测或上线后几小时才暴露。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
