Go range 读 Channel 为什么收不住：从发送方生命周期补上结束信号

先给结论：for v := range ch 不会因为“暂时没有值”而结束，它要等到 ch 被关闭。通常应由发送方在最后一次发送完成后调用 close(ch)，接收方只负责读取；如果接收方会提前离开，还要把取消信号传回上游。

下面用一个小实验把“收不住”拆开。代码可保存为 main.go，在 Go 1.20+ 环境执行 go run .。

先用一个最小例子确认 range 的结束条件

先看一个故意缺少关闭动作的发送方：

package main

import "fmt"

func main() {
	ch := make(chan int)
	go func() {
		ch 

输出 10 和 20 后，主 goroutine 仍会等待下一条消息，最后触发 fatal error: all goroutines are asleep - deadlock!。这不是 range 少读了数据，而是它没有收到“流结束”的信号。

把关闭责任放回发送方

修复只需要把关闭动作放在发送方完成的位置：

func produce() 

这里返回值是 ，调用方只能接收，接口本身也表达了“调用方不拥有关闭权”。不要让接收方为了结束 range 去调用 close(ch)，否则发送方稍后写入时会 panic。

多发送者不能各自随手 close

多个 worker 共享一个输出时，任何一个 worker 都无法证明“别人已经发完”。让协调者等待所有发送者，再由唯一位置关闭输出：

func merge(inputs ...

关键顺序是：先完成 wg.Add，再启动等待关闭的 goroutine；每个 worker 只调用 wg.Done，不触碰共享输出的关闭动作。这样消费者可以安全地继续 range merge(a, b)。

接收方提前退出时，用取消信号解开上游

如果消费者只取第一条结果就返回，worker 可能卡在 out ，即使 Channel 以后会关闭也等不到。发送动作应同时监听取消：

func worker(ctx context.Context, out chan

实际项目中可用 context.Context 贯穿请求、worker 和下游 I/O；仅在接收端设置超时，而发送端没有监听取消，仍然会留下 goroutine。检查时可以先用 go test -race ./... 找数据竞争，再用运行时 goroutine profile 观察是否有 worker 长期停在发送位置。

摘要：一是 range 的结束条件是关闭而不是“没有新值”；二是关闭权应归发送方或统一协调者；三是接收方提前退出必须广播取消，不能靠猜 buffer 大小。

相关问题

Channel 需要发送方还是接收方关闭？通常是发送方关闭，因为发送方知道最后一条值何时发出；多个发送方则交给协调者。

加大 buffer 能彻底解决阻塞吗？不能。只有发送总量和消费量都严格有界时，buffer 才能作为简单优化；未知规模的流水线应设计取消路径。

关闭后的 Channel 还能读吗？可以，已缓冲值会先读完，之后继续接收会得到元素类型零值；用双返回值接收可区分“零值数据”和“已关闭”。