Go 语言中 channel 关闭状态下重复关闭引发 panic 规避

重复关闭 channel 会直接 panic，Go 运行时强制禁止；应使用 sync.Once 封装 close() 确保单次执行；多数场景无需显式关闭，仅当接收方需通过 ok 判断关闭时才必须 close。

先说一个硬性规则：在 Go 里，对已经关闭的 channel 再调一次 close()，程序瞬间 panic，跑都跑不掉。这不是什么偶发 bug，而是语言层面的保护——它不搞“静默忽略”那一套，直接用 panic 告诉你“这里写错了”。

重复关闭 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
}

func (p *Producer) Close() {
    p.once.Do(func() { close(p.ch) })
}

不推荐用原子布尔值做状态判断

虽然 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 := <-ch 或 for range ch 明确感知“发送已终止”。如果接收方压根不关心这个信号，关了反而多一层出错可能。