Go channel 怎么设计一个可关闭的广播通知

如果几个 goroutine 都要等待“任务结束”或“停止继续发送”，最稳妥的广播方式通常不是向 channel 里发送几个占位值，而是关闭一个专门的通知 channel。关闭之后，所有接收方都能立即从同一个 channel 收到零值并继续执行；通知人数不需要提前知道。

先把一次发送和关闭广播分开

向 channel 发送一个值只会唤醒一个接收者；如果有五个 worker，就得发送五次，而且 worker 数量一变，停止协议就容易失配。关闭 channel 表示“后面不会再发送任何值”，对它的接收会持续成功，因此天然适合广播。

Go 语言规范规定，关闭 nil channel 会 panic，向已关闭的 channel 发送或再次关闭也会 panic；关闭后，接收操作在读完已发送值后会立即返回元素类型的零值。这个语义决定了通知 channel 不应该混装业务数据。

关闭权只交给一个协调者

可以把关闭通知设计成单向接收类型，让函数签名直接表达权限。下面的 worker 无法调用 close(done)，它只负责观察广播；只有 runWorkers 知道所有 worker 何时应该结束。

package main

// worker 只接收停止广播，不拥有关闭权。
func worker(done 

示例里的 done 用空结构体，是因为通知不需要携带数据。真实项目里可以启动多个 worker；关键不是启动数量，而是它们共享同一个接收端。

让 select 同时等待数据和停止信号

只在循环末尾检查一次 done 还不够：如果 worker 正卡在向下游发送，循环体根本没有机会回到检查点。发送分支也要放到 select 中，让“发送成功”和“广播关闭”竞争同一个等待位置。

func square(done 

这里有两个关闭动作，责任不同：外部协调者关闭 done 做广播，square 在自己不再产生结果时关闭 out。不要让下游接收者为了“帮忙收尾”关闭上游的输出 channel。

多个取消来源时用 sync.Once 收口

如果超时、错误和用户主动停止都可能触发取消，不能让三个分支直接执行 close(done)。用一个小的关闭函数集中处理，并由 sync.Once 保证只关闭一次；如果项目已经使用 context.WithCancel，则优先调用 cancel，把 channel 细节留给 Context。

type broadcaster struct {
    once sync.Once
    done chan struct{}
}

func (b *broadcaster) stop() {
    b.once.Do(func() {
        close(b.done) // 超时、错误等多个来源最终只执行一次。
    })
}

迁移时按四项回归检查走一遍：是否有唯一关闭者；所有可能阻塞的发送是否监听 done；业务数据 channel 是否仍由发送方关闭；worker 返回后是否能被等待或回收。尤其不要用“先判断 channel 是否关闭，再 close”的竞态写法，判断与关闭之间仍可能被另一个 goroutine 插入。

相关问题

关闭 channel 会把一个值广播给每个接收者吗？

不会。它广播的是“已关闭”这一状态；接收者读到的是元素类型的零值，并可通过双返回值判断关闭。

接收方能不能关闭 done？

通常不能。把关闭权留给创建并协调这条通知的代码，接收方只读，能从类型和结构上减少重复关闭。

通知 channel 应该缓冲吗？

纯关闭广播通常不需要缓冲，make(chan struct{}) 就能表达状态；缓冲不会改变关闭后的广播语义。