向已关闭 channel 发送数据必然 panic：Go 语言强制禁止该操作，运行时触发“send on closed channel”panic，根源是写入与关闭的时序冲突，常见于多 goroutine 共享 channel 且关闭职责不明。
向已关闭 channel 发送数据必然 panic
Go 语言明确禁止向已关闭的 chan 发送数据，运行时会直接触发 panic: send on closed channel。这不是偶发错误，而是语言强制约束——它在告诉你：写入操作与关闭操作存在时序冲突，逻辑上已不可恢复。
常见诱因是多个 goroutine 共享一个 channel，且未约定谁负责关闭、谁负责写入。比如消费者提前退出并调用 close(ch)，而生产者 goroutine 仍在循环执行 ch ，下一次发送就崩。
- 不能靠
recover()捕获并忽略——这掩盖了生命周期管理缺陷，后续难以调试 - 不能靠“先检查是否关闭”来规避——Go 没有公开 API 能安全判断 channel 是否已关闭
- 缓冲区满、channel 阻塞、超时等场景，和“已关闭”是不同问题，需分开处理
用 nil channel 技巧让 select 自动跳过写入
核心思路：让发送操作在 channel 关闭后“不可选”，而不是“选中后失败”。Go 的 select 对 nil channel 的 case 会永久忽略，正好用来做安全门控。
关键点是把实际 channel 赋值给一个局部变量，并只在允许写入时才赋值；否则让它保持 nil：
func writer(done <-chan struct{}, ch chan<- int) {
var writeCh chan<- int
for i := 0; ; i++ {
select {
case <-done:
close(ch)
return
default:
writeCh = ch // 仅当 done 未就绪时才启用写入
}
select {
case writeCh <- i:
case <-done:
close(ch)
return
}
}
}-
writeCh初始为nil，若done已就绪，default分支不执行，writeCh保持nil - 第二个
select中，writeCh <- i因writeCh == nil被跳过，不会 panic - 整个过程无需锁、无需原子变量，纯靠 channel 语义实现线程安全
避免双重关闭：用 sync.Once 封装关闭逻辑
多个 goroutine 都调用 close(ch) 是另一个高频 panic 来源，典型于测试中多个函数各自 defer close(ch)。
最稳妥的解法不是加状态判断，而是用 sync.Once 把“判断 + 关闭”原子化：
type Producer struct {
ch chan int
once sync.Once
}
<p>func (p *Producer) Close() {
p.once.Do(func() { close(p.ch) })
}-
sync.Once保证close(p.ch)最多执行一次，无论多少 goroutine 并发调用Close() - 比用
atomic.Bool更可靠：后者仍可能在读取false后、写入true前被另一个 goroutine 插入close() - 注意：必须确保所有关闭入口都走同一
Producer.Close()方法，不能混用裸close(ch)
哪些情况其实根本不需要 close()
很多人默认“用了 channel 就得关”，但多数时候这是多余动作，反而增加出错面。
真正需要 close() 的唯一动机是：让接收方能通过 v, ok := 或 <code>for range ch 明确感知“发送已终止”。如果接收方不依赖这个信号，关不关没区别。
- 缓冲 channel 用于内部 goroutine 协作，用
sync.WaitGroup等待写入完成即可，不必关 - 接收方是有限循环（如只取前 N 个值），且发送方也是有限循环，
for range会自然退出，无需关 - 信号类 channel（如
done chan struct{}）适合关闭，但数据通道往往不需要 -
close()不释放内存、不唤醒阻塞发送者、也不终止 goroutine——它只是个通知信号
最容易被忽略的细节是：关闭 channel 和“资源清理完成”完全不是一回事。哪怕你调了 close(ch)，只要还有 goroutine 在尝试 ch ，panic 就随时等着你。
