Go for-range channel 结束条件为什么依赖 close

Go 里用 for v := range ch 接收 channel 时，循环不会因为读到了某个“特殊值”就自动结束。真正的结束信号是：发送方关闭 channel，并且接收方已经把关闭前留下的值读完。也就是说，数据值和通道状态是两件事；即使业务值是 0、nil 或空字符串，也不能拿它代替 close。

for-range 退出的判断不是“收到零值”

接收表达式在 channel 关闭后仍会返回元素类型的零值，但同时把 ok 设为 false。如果只写一个变量，关闭状态就被隐藏了；for-range 则把这个判断封装起来，继续接收直到状态变成 closed 且没有待消费的数据。

package main

func consume(ch 

因此，发送一个约定的 -1 或空字符串作为“结束值”并不稳妥：它会把业务数据和控制信号混在一起，调用方也无法确认发送方是否真的完成。需要结束语义时，让状态由 close 表达。

close 让接收方知道最后一个值已经读完

关闭并不会丢掉已经发送的数据。对带缓冲 channel 来说，接收方会先读完缓冲区，再在下一次接收时得到零值和 ok=false；对无缓冲 channel，关闭表示后续不会再有发送。

这也解释了常见死循环：发送方发送完最后一个元素，却没有关闭 channel；接收方处理完元素后仍会等待下一次发送。若发送方本身也在等待接收方结束，就形成互相等待。

把关闭责任放在发送方一侧

一个实用约定是“谁决定不会再发送，谁负责 close”。单一生产者最容易满足这个约定：发送完所有结果后关闭；接收方只读，不负责猜测生产是否完成。

func numbers() 

多个发送方时不能让每个 goroutine 都调用 close，否则先关闭者之后仍可能发送，或者多个关闭者触发 panic。可以让一个协调者等待所有发送方结束，再统一关闭；如果没有任何一方能可靠判断“最后发送已完成”，就不应贸然关闭。

用通道方向和测试检查结束条件

把返回类型写成 能在接口层限制调用者只能接收，减少误关闭的机会。排查循环不退出时，按下面顺序检查：

1. 是否存在明确的发送方，以及它是否在所有发送路径结束后执行 close？
2. 是否有提前返回、错误分支或 goroutine 泄漏，让关闭代码永远走不到？
3. 是否有第二个发送方仍在发送，或接收方在等待一个永远不会到来的值？

func mustFinish(done 

实际项目中还要给这段示例补上 time 导入，并把超时测试放在测试代码而非核心业务逻辑里。核心判断始终不变：数据是否读完由接收结果决定，是否还会有新数据由发送方的关闭动作决定。

相关问题

channel 关闭后还能发送吗？

不能。向已关闭 channel 发送会触发 panic，所以发送方必须保证关闭发生在最后一次发送之后。

接收方能不能关闭 channel？

只有接收方明确拥有“不会再发送”的生命周期权时才可以；常规生产者—消费者模型中，应由发送方或统一协调者关闭。

不 close 能不能用 break 退出？

可以，但必须有独立且可靠的结束信号，并在退出时处理生产 goroutine；仅靠 break 不能自动阻止另一端继续发送。