for range in 会导致卡死，因为range必须等待channel关闭才退出，而漏掉goroutine启动、显式关闭或defer关闭任一环节，均无法发出“不再有新值”信号，致使循环永久阻塞。
直接结论：每个过滤器必须启动 goroutine、显式关闭输出 channel、且关闭动作必须 defer 在 for-range 循环结束后 —— 漏掉任一环节，轻则卡死，重则 panic。
为什么不能写 for s := range in { out 就完事
这行代码看着简洁，但上线就出问题。根本原因不是语法错，而是它把“等待输入”和“退出时机”全交给了上游，自己完全不设防：
- 上游没
close(in)，这个range就永远阻塞，整个 stage 卡住不动 - 上游关了，但下游还没开始
range out，你这边已经退出，out没关，下游会永远等 - 更糟的是，如果中间某次
transform()panic，out根本没机会 close，下游彻底收不到 EOF
func(in 的标准写法长什么样
这不是风格问题，是 runtime 安全边界。正确模板只有一种：
func upperCase(in <-chan string) <-chan string {
out := make(chan string, 16)
go func() {
defer close(out) // 必须 defer，且只能在这儿
for s := range in {
out <- strings.ToUpper(s)
}
}()
return out
}关键点：
立即学习“go语言免费学习笔记（深入）”；
-
make(chan string, 16)：缓冲大小选 16 是经验值，纯内存转换类 stage（如strings.ToUpper）用 1–16 足够，太大反而掩盖背压问题 -
defer close(out)：必须在 goroutine 内部、循环结束后触发，不能提前，也不能漏 - 不暴露 goroutine 启动逻辑给调用方：函数签名仍是纯函数式，内部并发对使用者透明
多个 stage 串起来时，close 怎么不冲突不漏关
链越长，关 channel 的责任越容易错位。常见错误是每个 stage 都自作主张 close(out)，结果第二个 stage 写入时 panic：send on closed channel。
真正安全的协作规则：
- 源头（generator）负责
close它创建的首个out - 中间每个 stage 只
defer close(out)，且仅对自己 goroutine 内的for s := range in负责 - fan-in 场景（比如 3 个 worker 往同一个
out写）：绝不能让 worker 自己关out，要用errgroup.Group等全部 worker 结束后，由主 goroutine 统一close(out) - 所有 stage 必须监听
ctx.Done()，收到 cancel 就立即退出循环并让defer close(out)执行
什么时候该放弃 channel 管道，改用普通函数链
channel 不是万能胶。如果你只是对几行字符串做 strings.TrimSpace → strings.Split → filterEmpty，硬套管道反而引入三重 goroutine 开销、channel 创建/销毁成本、以及一堆关闭逻辑。
适合直接函数组合的信号：
- 输入数据量小（string 或全是
[]byte） - 无流式需求（不需要边读边处理）、无并发摊平延迟的需求（比如没有外部 HTTP 调用）
- 不需要背压控制（上游不会猛灌，下游也不会慢得离谱）
- 调试简单：函数调用栈清晰，panic 位置一眼可见；而 channel 死锁或 panic 往往只报
send on closed channel，却找不到谁先关的
最易被忽略的一点：每个 defer close(out) 必须和它对应的 for s := range in 在同一个 goroutine 里结束。跨 goroutine 关闭，就是 runtime panic 的温床。
