向已关闭通道发送数据会触发 panic: send on closed channel，导致程序崩溃；Go 采用 panic 而非 error 是为强制显式建模生命周期，避免竞态引发的静默失败、数据丢失或 goroutine 泄漏。
向已关闭的 channel 发送数据会 panic
直接后果是程序崩溃，触发 panic: send on closed channel。这不是错误返回值，而是运行时不可恢复的 panic，除非用 recover() 捕获——但捕获它通常意味着设计有误，不建议这么做。
为什么 Go 要设计成 panic 而不是返回 error？
channel 关闭是一个明确的语义信号：「发送端不会再发新数据了」。接收端靠 v, ok := 中的 ok 判断是否结束；如果发送端还能继续发，就彻底破坏了这个契约。
- 关闭是单向、不可逆操作，且只能由 sender 执行
- 多个 goroutine 并发写同一 channel 时，无法靠锁或标志位 100% 防止重复关闭或误发 —— panic 是最直接、最暴露问题的失败反馈
- 接收端可以优雅退出（比如
for range ch自动终止），但发送端没有「软关闭」的合法场景
哪些操作也会 panic？顺便对照排查
容易被忽略的同类 panic 场景有三个，和「向已关闭 channel 发送」并列，都是 runtime 层面的硬性限制：
-
close(nil)：对 nil channel 调用close() -
close(ch)两次：对已关闭的 channel 再次调用close() ch ：向已关闭的 channel 发送数据
这三类 panic 都不会被编译器检查，只在运行时爆发，尤其在并发复杂、关闭逻辑分散的代码中容易踩坑。
实际编码中最容易出错的两个地方
不是记不住规则，而是结构上容易绕晕：
- 多个 goroutine 共同向一个 channel 发送，但关闭逻辑没收敛到唯一出口 —— 比如一个 worker 完成后就
close(ch)，其他 worker 还在往里塞数据 - 在
select的default分支里盲目发送，没先确认 channel 是否已关闭或是否还有 receiver
真正安全的做法是：确保只有**一个 goroutine** 负责关闭 channel（通常是最后一个 sender），其他 sender 在发送前不做状态判断，而是依赖该 goroutine 的关闭时机来自然退出 —— 或者干脆不用 close()，改用 done chan struct{} 做协调信号。
