向已关闭 channel 发送必然 panic，错误固定为 panic: send on closed channel，这是 Go 运行时强制禁止的操作，体现语言层面对“关闭即终结”契约的严格执行。
向已关闭 channel 发送必然 panic
Go 运行时强制禁止该操作，错误固定为 panic: send on closed channel。这不是偶发异常，而是语言层面对“关闭即终结”契约的严格执行——close(ch) 表达的是“发送端终止”，不是“暂停”或“可重置”。一旦关闭，任何后续 ch 都会立即终止当前 goroutine。
常见错误现象包括：
- 多个 goroutine 共享同一
ch，各自调用close(ch)导致双重关闭 panic - 生产者 goroutine 在
for range退出后未同步等待就直接close(ch)，而其他写入 goroutine 尚未结束 - 误以为
recover()可兜底，结果掩盖了生命周期管理缺陷，调试时难以定位谁先关、谁还在发
为什么不能加 IsClosed() 或 TrySend()
Go 没提供 IsClosed(ch)、TrySend() 等安全接口，是因为它拒绝用 API 掩盖逻辑问题。如果代码里出现“不确定 channel 是否已关，但还想发”的场景，说明设计本身就有缺陷：发送方和关闭方职责未对齐，或缺少明确的退出信号协调机制。
真实使用场景中，你需要的是：
立即学习“go语言免费学习笔记（深入）”；
- 用
done 作为外部取消信号，而非轮询 channel 状态 - 把写入操作封装进
select，配合局部writeCh变量动态置为nil，让不可选分支自动跳过 - 避免在
defer close(ch)中隐含“我是唯一写入者”的假设——若 goroutine 可能被多次启动，defer 就会重复触发 close
select + nil channel 是唯一安全写入控制方式
核心思路是让发送分支在 channel 关闭后“不可选”，而不是“选中后再失败”。Go 的 select 对 nil channel 的 case 会永久忽略，这正是天然的安全门控。
典型写法如下：
func writer(done <-chan struct{}, ch chan<- int) {
for i := 0; ; i++ {
var writeCh chan<- int
select {
case <-done:
close(ch)
return
default:
writeCh = ch // 仅当 done 未就绪时才启用写入
}
select {
case writeCh <- i:
case <-done:
close(ch)
return
}
}
}关键点：
-
writeCh = ch必须放在default分支中，确保done就绪后writeCh保持nil - 第二个
select中，writeCh <- i分支因writeCh == nil被跳过，不会 panic - 整个过程无锁、无原子变量，纯靠 channel 语义实现线程安全
真正容易被忽略的是关闭时机与接收端行为错位
很多人以为“关了 channel 就万事大吉”，但实际问题常出在接收端：比如用 for range ch 的接收方，在发送端调用 close(ch) 后仍可能读到一次零值（尤其无缓冲 channel），因为调度器可能让接收 goroutine 抢在 close 执行完前进入下一轮循环。
修复的关键不是改接收逻辑，而是分离动作：
- 先通过
done通知接收方“该退出了” - 接收方收到
<-done后主动 break，再由统一入口调用close(ch) - 若必须用
for range，则发送端需确保所有ch <- v已返回，再 close；不能依赖sync.WaitGroup.Wait()后立刻 close，WG.Done() 和 close() 之间存在竞态窗口
