Go channel 关闭 range 什么时候才能结束

Go 里 for value := range ch 什么时候结束？答案是：ch 已经关闭，并且关闭前发送到其中的值已经全部被接收。发送方暂时没有数据，只会让接收方等待；如果一直没人调用 close，这个循环就可能永久阻塞。

把 close 理解成“不会再有新值”的广播，而不是“现在没有值”。通常由最后一个发送责任方关闭 channel，接收方只负责 range 读取。

range 接收循环到底在等待什么

channel 的接收操作有两个结果：一个元素值，以及“是否仍然开放”的状态。单值写法把状态隐藏了，所以 range 会持续做接收：有值就交给循环体，没有值但 channel 尚未关闭就继续等待；关闭后，如果缓冲区还有值，先把这些值读完，之后才结束。

因此下面的生产者必须在发送完成后关闭。main 不是因为“发送了三个值”自动知道结束，真正的结束信号来自 close。

package main

import "fmt"

func produce(out chan

由谁 close 才能让 range 正常结束

关闭规则可以压缩成一句话：谁能证明“以后不会再发送”，谁负责关闭。单生产者模型中，生产函数最清楚这个边界；接收方通常不知道上游是否还有工作，不应该为了让自己的循环结束而主动关闭。

多个生产者共享一个输出 channel 时，不能让每个生产者都执行 close(out)。第一个完成的生产者关闭后，其他生产者继续发送就会触发运行时 panic。更稳妥的做法是让协调 goroutine 等待全部生产者结束，再统一关闭。

package main

import "sync"

func merge(a, b 

用双值接收检查关闭状态

在 select、需要提前返回或必须区分零值的代码里，可以显式接收第二个结果：

for {
	value, ok := 

这也是理解 range 的最好方式：它等价于不断接收，并在 ok == false 时结束。关闭后的 channel 可以继续接收，但只能得到已经排队的值；队列排空后返回元素类型的零值与 false。

nil channel、缓冲 channel 和提前退出的边界

nil channel 永远不能完成发送或接收。对 nil channel 使用 range，循环会一直等；对它调用 close 则会 panic。所以创建 channel 的函数应明确返回已初始化的 channel，取消路径也不能靠“把 channel 置 nil”来通知消费者。

缓冲 channel 也不会改变结束条件，只改变等待位置：关闭后，缓冲区里已有的值仍然要被消费。另一个常见坑是接收方提前退出，导致生产者卡在发送操作上。流水线需要配合 context.Context 或取消 channel，让生产者在下游不再消费时停止发送，否则 range 虽然结束了，上游 goroutine 仍可能泄漏。

相关问题

发送完数据后不 close，range 会自动结束吗？

不会。channel 不记录“发送方已经自然返回”这件事；只要没有关闭，接收方就可能继续等待。

close 后还能读到值吗？

能。关闭前已经发送的值会先被接收；排空后才得到零值和 ok == false。

应该由接收方关闭 channel 吗？

通常不应该。接收方无法确认是否还有发送者，应该由最后一个发送责任方或协调器关闭。