重复关闭 channel 会直接 panic，go 运行时强制禁止；应使用 sync.once 封装 close() 确保单次执行；多数场景无需显式关闭，仅当接收方需通过 ok 判断关闭时才必须 close。
重复关闭 channel 会直接 panic
Go 运行时明确禁止对已关闭的 channel 再次调用 close()，一旦触发，程序立即崩溃并抛出 panic: close of closed channel。这不是偶发行为，而是语言层强制的保护机制——它不尝试“静默忽略”，而是用 panic 暴露逻辑错误。
常见诱因包括：
- 多个 goroutine 竞争关闭同一个
channel（比如生产者协程 + 超时清理协程同时判断该关） - 封装的关闭逻辑未做状态检查，被多次调用（如回调函数、重试逻辑中误触发）
- 在 defer 中无条件
close(ch)，但主流程已提前关闭过
用 sync.Once 封装单次关闭最稳妥
sync.Once 是 Go 标准库提供的轻量级线程安全工具，保证其包裹的函数只执行一次。它比手动加锁或原子变量更简洁，也比自己维护 closed bool 更可靠（避免竞态读写）。
实操建议：
- 将
close(ch)包裹进sync.Once.Do()，哪怕调用一百次也不会 panic - 不要把
sync.Once放在局部变量里（比如函数内声明），否则每次调用都新建一个，失去意义 - 推荐绑定到结构体字段，让生命周期与
channel一致
示例：
type Producer struct {
ch chan int
once sync.Once
}
<p>func (p *Producer) Close() {
p.once.Do(func() {
close(p.ch)
})
}
</p>
不推荐用原子布尔值做状态判断
虽然 atomic.Bool 看似能解决“是否已关”的问题，但它存在两个隐蔽风险：
- 无法防止
close()调用本身被并发执行：A 协程刚读到false，B 协程就close()了，A 接着也close()—— 依然 panic - 必须严格配对使用
CompareAndSwap和close()，稍有疏漏（比如漏掉判断分支）就会绕过保护
相比之下，sync.Once 把“判断 + 执行”原子化封装，开发者只需关注“我要关”，不用操心“有没有人先关”。
哪些场景其实根本不需要 close？
很多人默认“用了 channel 就得关”，但实际多数情况可以跳过 close()：
- 缓冲通道（
make(chan T, N)）只用于内部协程通信，生命周期由sync.WaitGroup控制 - 接收方用
for range ch读取，而发送方是有限循环且不会 panic，那range会在发送结束自动退出，无需显式close() - channel 作为信号通道（如
done chan struct{}），用close(done)是合理的；但若只是传递数据，且接收方不依赖ok判断关闭，关不关没区别
真正需要 close() 的核心动机只有一个：**让接收方通过 v, ok := 或 <code>for range ch 明确感知“发送已终止”。** 如果接收方压根不关心这个信号，关了反而多一层出错可能。
