Go 如何让多个生产者在不抢 close 权限的情况下退出

多个 goroutine 同时往一个 channel 发送数据时，最容易写错的地方不是启动生产者，而是“谁来 close”。安全的答案很明确：生产者只负责发送和响应停止信号，不能抢着关闭共享的数据通道；由一个协调者等所有生产者退出后，再执行一次 close(out)。这样既不会出现重复关闭，也不会让仍在发送的 goroutine 撞上已关闭通道。

先把数据通道和停止信号分开

close(out) 表示“以后不会再有任何值发送到 out”。它不是“请大家停止工作”的按钮。Go 规范规定，向已经关闭的通道发送，或者再次关闭该通道，都会触发运行时 panic。因此，当生产者数量大于一个时，让每个生产者在结束时调用 close(out)，职责天然冲突。

更稳的模型是准备两个方向不同的通道：out 只承载业务数据，done 或 ctx.Done() 只承载停止广播。关闭停止信号不会关闭数据通道，生产者收到取消后先从自己的函数返回；数据通道仍由外层协调者管理。

让多个生产者响应同一个停止事件

生产者发送时不要直接写成阻塞的 out 。如果消费者提前返回，发送方可能永远卡住。把发送和取消放进同一个 select，就能让它在两种情况之间选择：有接收者时发送，没有接收者但上下文已取消时退出。

package main

import (
    "context"
    "sync"
)

type Item struct {
    Producer int
    Number   int
}

func produce(ctx context.Context, id int, out chan

这里有一个容易被忽略的边界：如果发送分支和 ctx.Done() 同时就绪，select 会从可执行通信中选择一个，所以取消发生后可能还会成功发送一项。若业务要求“取消后绝不再提交”，需要在发送前增加业务层状态检查或使用带序号的提交协议，不能把 select 当成严格的事务闸门。

让唯一协调者在 Wait 返回后关闭 out

关闭时机应该由生产者集合之外的协调者掌握。先完成所有 Add，再启动 goroutine；每个生产者通过 Done 报告结束，等待 goroutine 负责收尾。只要 Wait 尚未返回，就不能关闭 out。

func stream(ctx context.Context, producerCount int) 

完整消费时，调用方可以直接 for item := range stream(ctx, 3)，直到协调者关闭 out 才自然结束。提前停止时，调用方先取消上下文，生产者离开发送循环，等待 goroutine 随后关闭通道。若把 close(out) 放在取消动作之前，仍有发送者可能在关闭后写入，panic 就会重新出现。

几个容易误判的关闭场景

• 用 sync.Once 包住 close：它只能避免多次关闭，不能阻止另一个 goroutine 在关闭后发送；发送者仍需先退出。
• 让接收者负责 close：接收者通常不知道还有多少生产者，也无法证明未来不会再有发送，除非协议明确规定它拥有完整生命周期。
• 把 done 和 out 合成一个通道：关闭 out 会同时改变数据协议和停止协议，容易让职责交叉；拆开后更容易检查。
• 动态增加生产者：如果 Add 发生在计数为零且 Wait 已可能开始之后，生命周期就不安全。先登记任务，再等待。

相关问题

多个生产者可以共享一个只发送通道吗？

可以。把 out 以 chan 传给生产者，能在类型层面限制它只能发送；但关闭权限仍由创建并协调生命周期的一方保留。

关闭 done 后还需要关闭 out 吗？

需要。done 只表示停止信号；消费者的 range out 要结束，仍需要协调者在所有生产者退出后关闭 out。

为什么不直接 recover 发送 panic？

因为 recover 只是掩盖错误时序，不能恢复丢失的数据，也不能保证其他生产者已停止。修正关闭者和等待关系，才是可维护的方案。

记住这条判断线：谁产生数据，谁就不能单方面宣告共享数据流结束；谁能证明所有发送者都已结束，谁才可以关闭输出通道。

官方资料

• Go 语言规范：Close：查看关闭、发送和接收的语义。
• Go Concurrency Patterns: Pipelines and cancellation：查看 done 通道广播取消的并发流水线模式。
• context 包文档：查看 Done 和 CancelFunc 的生命周期说明。
• sync 包文档：查看 WaitGroup 的 Add、Done、Wait 约束。