Go 用 close(channel) 广播退出时怎么避免重复关闭

在 Go 里，close(done) 很适合做退出广播：所有等待 的 goroutine 都会被同时唤醒。但关闭动作本身不是幂等的，第二次执行 close(done) 会触发 panic。最稳妥的规则是先确定唯一关闭者；如果停止请求可能来自多个调用点，就把关闭动作包进 sync.Once，让“请求停止”可以重复，而“真正关闭通道”只能发生一次。

为什么 close(done) 会成为广播退出信号

关闭一个元素类型为 struct{} 的通道，不需要发送具体数据。关闭完成后，所有接收操作都可以立即继续；用双值接收时，ok 会变成 false。因此，一个关闭动作就能通知任意数量的等待者。

这里的通道只承担退出信号，不承担业务数据。把它暴露成 ，可以从类型上禁止下游发送或关闭：

package main

import "fmt"

func worker(done 

这也是 Go 并发管道中常见的取消思路：信号通道的拥有者关闭它，工作 goroutine 只接收。不要让每个 worker 都尝试关闭同一个 done，否则广播模型反而会变成竞争关闭。

单一关闭者时如何保证 close 只发生一次

如果只有一个组件能够决定整个流程结束，最简单的设计是把关闭权留在该组件，并用 defer 覆盖正常返回和错误返回。调用者可以重复触发内部错误处理，但关闭动作仍然只在一个明确的位置发生。

func runPipeline() {
	done := make(chan struct{})
	defer close(done) // 单一关闭者：函数退出时广播一次

	startWorkers(done)
	if err := loadInput(); err != nil {
		// 直接返回也会先执行上面的 defer，通知所有 worker。
		return
	}
	finishInput()
}

这段写法适合“生命周期跟随函数”的场景。它的关键不是 defer 语法，而是关闭权没有被传给多个层级。若 startWorkers、HTTP handler 和超时回调都能调用停止函数，就已经不是单一关闭者问题了。

多个停止请求如何用 sync.Once 收口

当停止请求可能同时来自错误处理、超时和外部调用时，可以让这些入口都调用同一个 Stop。sync.Once.Do 保证闭包最多执行一次；它不会吞掉通道关闭之外的业务错误，也不会让一个数据通道自动变得安全。

package main

import "sync"

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

func NewStopSignal() *StopSignal {
	return &StopSignal{done: make(chan struct{})}
}

func (s *StopSignal) Done() 

这个封装把两个概念分开：Stop 是可重复调用的请求，close(s.done) 是一次性的状态转换。生产代码中可以让 worker 在循环的 select 里监听 s.Done()，而错误路径、超时回调和父流程都只调用 s.Stop()。

close(channel) 的边界与检查清单

最容易误用的是把“广播退出”套到业务数据通道上。数据通道应该由发送方在确认不会再发送后关闭；接收方通常不应关闭它。若取消来源已经是请求上下文，也可以直接使用 context.WithCancel，让框架管理 Done() 通道，而不要同时维护两套取消状态。

常见问题

sync.Once 能防止发送者在 close 后继续发送吗？

不能。它只保护传入的函数执行一次。发送者仍要通过 select 监听退出信号，并在结束前完成自己的发送协调。

可以用 recover 处理重复 close 吗？

不建议。重复关闭通常说明所有权设计有问题，sync.Once 或单一关闭者更能表达正确意图；recover 只会掩盖竞争。

什么时候应该改用 context.WithCancel？

当取消需要沿请求、数据库调用或多个 API 层传播时，优先传递 context.Context。只在局部 goroutine 组内广播退出时，独立的 done 通道通常更直接。

判断这类代码是否安全，可以只问三件事：谁拥有关闭权、是否存在多个停止入口、数据发送者是否能在退出时停下来。答案明确后，close(done) 才会真正成为可靠的广播机制。