Go 从 channel range 退出后怎么确认发送方也结束了

很多人看到 for v := range ch 结束，就默认“发送方已经退出了”。这个判断并不成立：range 结束只说明 channel 已被关闭，并且关闭前已经发送的值也读完了；发送方 goroutine 可能仍在别处工作，或者已经因为没人接收而阻塞。要确认它真的结束，必须设计一个独立的完成信号，并在接收方提前退出时主动取消发送。

让发送方负责关闭数据 channel；用 WaitGroup 汇总所有发送协程，再关闭 senderDone 作为“发送方已结束”的明确证据。接收方如果提前退出，先取消 context，再等待这个信号。

先区分 range 结束和发送方结束

Go 规范规定，对 channel 使用 range 会持续接收，直到 channel 关闭；如果 channel 还有缓存，关闭后这些值仍会先被读出。因此循环结束是一个“数据边界”信号，而不是“所有生产者已经返回”的信号。

例如接收方只取到第三个值就返回，发送方下一次执行 out 时可能永远等不到接收者。无缓冲 channel 最容易暴露这个问题，有缓冲 channel 也只能暂时把问题推迟。

让发送方关闭 channel，再汇总完成状态

多个发送协程共享一个输出 channel 时，不要让每个协程都直接 close(out)，否则先结束的协程会与仍在发送的协程发生竞态。常见做法是由协调 goroutine 等待全部发送方，再统一关闭输出和完成信号。

func stream(ctx context.Context) (

这里的关键不是“用了两个 goroutine”，而是关闭顺序：发送方先全部 Done，协调器再关闭 out。所以接收方看到 range 结束时，发送完成的条件已经成立；需要显式确认时，再接收 senderDone。

接收方提前退出时，先取消再等待

自然读完时，out 的关闭会结束 range；但业务常常只需要前几个结果。此时不能简单 break 后离开函数，应该把取消信号传给发送 select，并等待完成通知。

func consume() {
    ctx, cancel := context.WithCancel(context.Background())
    defer cancel() // 兜底覆盖其他返回路径

    out, senderDone := stream(ctx)
    for value := range out {
        if value == 12 {
            cancel() // 让阻塞发送方获得退出机会
            break
        }
        fmt.Println(value)
    }

    

取消只表示“请停止”，不等于发送方已经停止； 才是等待结果。若发送方还访问文件、连接或其他资源，也应把清理动作放在发送协程的 defer 中，让完成信号出现在清理之后。

用这张检查表判断是否真的收拢

还要注意关闭语义：对已关闭 channel 再发送或再次关闭会 panic；nil channel 上的通信则不会就绪。完成 channel 通常只由协调器关闭一次，接收方只读它，不承担关闭责任。

相关问题

range channel 一定会自动关闭吗？

不会。range 不负责关闭 channel；没有发送方调用 close，循环会一直等待。

close(out) 能证明发送 goroutine 已退出吗？

如果关闭动作由等待所有发送方的协调器执行，可以证明；如果某个发送方直接 close，则不能据此推断其他发送方已结束。

只用 WaitGroup 不用 senderDone 可以吗？

可以。调用方能拿到 WaitGroup 时直接 Wait；把完成状态封装在流式函数里时，关闭 senderDone 通常更容易保持只读边界。