close()重复调用必panic，Go语言强制禁止；sync.Once封装关闭最稳妥，需作为结构体字段绑定channel生命周期；多数场景无需close，仅当需通知接收方通道关闭时才应调用。
close() 被重复调用直接 panic，没有绕过方式
Go 运行时强制禁止对已关闭的 channel 再次调用 close()，一旦触发，程序立即崩溃并输出 panic: close of closed channel。这不是可配置行为，也不是偶发 bug，而是语言层的硬性约束——它不静默忽略，也不返回错误，只用 panic 暴露逻辑缺陷。
常见触发场景包括：
- 多个 goroutine 竞争判断是否该关（比如生产者 + 超时协程都执行了
close(ch)） - 函数内
defer close(ch)和主流程中已手动close(ch)，导致重复 - 封装的关闭方法被回调、重试、事件多次触发，未加防护
用 sync.Once 封装是最稳妥的单次关闭方案
sync.Once 把“判断是否已执行”和“执行关闭”原子化打包，比自己维护 atomic.Bool 或互斥锁更轻量、更可靠。关键点在于生命周期绑定：
- 不能在函数内声明局部
sync.Once，否则每次调用都新建一个，失去意义 - 必须作为结构体字段，与
channel同生共死，例如：type Service struct { ch chan int once sync.Once } func (s *Service) Shutdown() { s.once.Do(func() { close(s.ch) }) } - 如果
ch可能为nil，需额外判空：if s.ch != nil { close(s.ch) }
哪些情况其实根本不用 close()
很多 panic 其实源于“以为必须关”。实际上，close() 唯一正当动机是：让接收方通过 v, ok := 或 <code>for range ch 感知到“发送已终止”。其他情况往往可以跳过：
立即学习“go语言免费学习笔记（深入）”；
- 缓冲通道（
make(chan T, N)）仅用于内部 goroutine 通信，靠sync.WaitGroup控制生命周期 - 接收方用
for range ch，而发送方是有限循环（如发 100 个就结束），range会在最后自动退出，无需提前close() - 信号通道（如
done chan struct{}）才适合close(done)；纯数据通道若接收方不依赖ok判断，关不关没区别
向已关闭 channel 发送数据的 panic 更难调试
这和重复 close() 是两类问题，但常被混淆。它报的是 panic: send on closed channel，根源是写操作没受控。正确做法不是 recover，而是让发送分支在 channel 关闭后“不可选”：
- 用
select+nil通道技巧：把写通道变量设为nil，select中对应case就永久阻塞，自然跳过 - 避免在
select的default分支里无条件发数据——default会立刻执行，不管 channel 是否已关 - 最干净的解法仍是所有权归一：只让一个 goroutine 负责写 + 关，其他协程不碰
close()，也不直接写
sync.Once 必须和 channel 绑定在同一作用域生命周期内**。放在局部函数里、或每次 new 一个新结构体却不复用 once 字段，都会让防护失效。 
