向已关闭的 chan 发送数据会立即 panic，Go 运行时强制禁止该操作，触发“send on closed channel”错误，根源是写入与关闭的时序冲突，且关闭语义为单向终结信号。
向已关闭的 chan 发送数据会立即 panic
Go 运行时对此有硬性检查：只要执行 ch 且 <code>ch 已关闭，就会触发 panic: send on closed channel，不会延迟、不会静默失败。这是编译器无法捕获的运行时错误，必须靠逻辑控制规避。
- panic 发生在发送语句执行瞬间，不是在 close() 调用时
- 哪怕 channel 是 nil，
ch 也会阻塞（永不 panic），但关闭 nil channel 才会 panic —— 这和“向已关闭 channel 发送”是两个独立错误路径 - recover 无法捕获该 panic：它属于 runtime 级别强制终止，不是普通 panic 可拦截范畴（实测
defer/recover对其无效）
为什么 Go 不允许向关闭 channel 发送，但允许从关闭 channel 接收
设计上，channel 关闭表示“生产结束”，接收方可通过 v, ok := 中的 <code>ok 判断是否已无新数据；而发送端若还能发，就违背了“关闭=不再生产”的语义。允许接收是为了让消费方安全 drain 剩余数据。
- 从已关闭 channel 接收：立刻返回零值 +
ok=false，不 panic - 从 nil channel 接收：永久阻塞（和发送一样）
- 关闭已关闭的 channel：直接 panic ——
close(ch)本身也有单次约束
常见误用场景与防御写法
典型出错点不是“故意关完还发”，而是并发下关闭时机不可控，比如多个 goroutine 协作时，A 关闭 channel，B 还没收到通知就尝试发送。
- 用 sync.Once 或显式状态标志（如
atomic.Bool）配合 channel，先置标志再 close，发送前检查标志 - 避免在 select 的 default 分支里无条件发数据 —— 若 channel 此刻被关，default 会立即执行并 panic
- 不要依赖 defer close(ch) 在函数退出时关 channel：如果函数内有异步 goroutine 持有该 channel 并可能发送，defer 就成了雷
- 更稳妥的做法：由唯一 sender 控制生命周期，receiver 不负责关 channel；或使用带缓冲 channel + 显式 done signal 替代 close
测试时如何复现和验证该 panic
本地快速验证只需两行：
立即学习“go语言免费学习笔记（深入）”；
ch := make(chan int, 1) close(ch) ch <- 42 // 这里 panic
但在真实并发中，它往往偶发且难复现。建议在单元测试中主动构造竞争：
- 启动一个 goroutine 执行
close(ch) - 主 goroutine 立即循环
ch ，大概率在第 1–2 次就 panic - 用
go test -race可辅助发现 close 和 send 的竞态，但 race detector 不报这个 panic，它只报数据竞争 —— 所以仍需逻辑自查
真正容易被忽略的是：panic 不发生在 close 那一刻，而是在下一个发送动作；而那个动作，可能藏在深层调用栈、第三方库回调、或定时器触发的 goroutine 里。
