设计只由发送方关闭的多阶段数据管道

多阶段 Channel 管道真正难维护的地方，不是把 goroutine 串起来，而是每个阶段结束时谁来关通道。我踩过的坑是让下游“顺手”关闭输入 Channel：正常流量下似乎没问题，一旦上游仍在发送，就会直接出现 send on closed channel。

更容易推理的规则是：每个阶段创建自己的输出 Channel，完成全部发送后由该阶段关闭；下一阶段只接收，不关闭输入。数据按这个规则单向流动，关闭信号也会自然从上游向下游传播。

官方管道参考：https://go.dev/blog/pipelines

close 语义：https://go.dev/ref/spec#Close

先定一条所有权规则

把一个阶段看成小组件，它通常有一个只读输入和一个只读输出：

• 输入参数使用 ，表示该阶段只能接收；
• 阶段内部创建双向 Channel，用于发送结果；
• 对外只返回 ，调用方无法反向写入；
• 内部发送 goroutine 使用 defer close(out)，覆盖正常完成和取消退出；
• 下游用 range 接收，直到上游关闭输出。

这种接口的体验很好：调用者只需要组合函数，不需要记住“谁关哪个 Channel”；所有权已经由函数签名和创建位置表达出来。

完整示例：源、转换、过滤、汇聚

下面实现一条三阶段数据管道：源阶段产生整数，转换阶段把数值乘以 3，过滤阶段只保留偶数，主函数作为汇聚端消费最终结果。每个阶段都支持 context 取消。

package main

import (
	"context"
	"fmt"
)

func source(ctx context.Context, values ...int) 

这段程序会依次输出 6、12、18。更关键的是退出顺序：source 发送结束后关闭 raw；multiply 读完 raw 后关闭 mapped；filter 读完 mapped 后关闭 filtered；最终 range filtered 自动结束。

为什么发送和接收都要监听 context

只在接收处检查取消还不够。某个阶段可能已经算出结果，却因为下游不再接收而阻塞在 out 。因此每个可能阻塞的发送点都要用 select 同时等待“发送成功”或“收到取消”。

同理，若上游迟迟不关闭输入，阶段也可能卡在接收处；接收和取消也应放进同一个 select。这样不论阻塞发生在管道哪一侧，取消都能让 goroutine 退出。

下游提前结束时广播取消

如果汇聚端只需要第一个结果，不能接收一次后直接返回，否则上游可能永远阻塞在发送。正确做法是先调用 cancel()，再结束消费：

ctx, cancel := context.WithCancel(context.Background())
defer cancel() // 保证所有退出路径都会广播取消。

out := filter(ctx, multiply(ctx, source(ctx, 1, 2, 3, 4), 3), func(v int) bool {
	return v%2 == 0 // 示例只保留偶数。
})

if first, ok := 

这里关闭的是 context 的取消信号，不是某个上游阶段的数据 Channel。每个阶段收到取消后自行退出，并通过自己的 defer close(out) 结束输出生命周期。

多 worker 阶段怎么保持发送方关闭

如果一个阶段内部有多个 worker，它们共同向同一个输出 Channel 发送。此时任何单个 worker 都不能关闭输出，因为其他 worker 可能仍在发送。解决方式是在阶段内部增加一个协调 goroutine：等待所有 worker 完成，再关闭共享输出。

func parallelMap(
	ctx context.Context,
	in 

“只由发送方关闭”并不等于“由任意发送 goroutine 关闭”。在多 worker 阶段中，整个阶段是输出的所有者，协调 goroutine 代表阶段完成关闭。

边界状态怎么处理

性能与可维护性检查

• 不要用超大缓冲掩盖取消问题：缓冲只能推迟阻塞，不能保证上游退出。
• 只读/只写方向写进签名：让错误在编译期暴露，减少维护者误关输入 Channel 的机会。
• 错误也要能终止管道：某阶段失败后应取消剩余阶段，避免无用计算和 goroutine 泄漏。
• 为阶段命名和计时：在生产系统中记录每阶段处理数量、耗时和取消原因，便于定位背压位置。
• 限制并发 worker 数量：不要让输入中的每个元素都创建一个无限增长的 goroutine。

常见问题

接收方什么时候可以关闭 Channel？

只有当接收方同时拥有并控制全部发送生命周期时才可以，但这时它实际上扮演的是协调者，而不是普通接收者。一般组件接口中，接收方不应关闭输入。

每个阶段都必须关闭输出吗？

如果下游需要用 range 或 ok 判断完成，就应该关闭。若协议已明确只接收固定次数，也可以不关闭。关闭的目的是传达“不会再有值”，不是垃圾回收要求。

数据 Channel 和 done Channel 的关闭规则一样吗？

底层语义一样，但所有权不同。数据 Channel 通常由产生数据的一方关闭；done 或 context 由负责结束整个操作生命周期的协调者触发，用于向多个阶段广播停止。

一条好维护的 Go 管道，调用者看到的是连续、可组合的只读 Channel；实现者遵守的是清晰的所有权：创建输出、完成发送、关闭输出。再配合统一取消信号，正常完成和提前退出都能沿着同一套规则收尾。