向已关闭channel写入会立即panic，因Go语言强制禁止该操作，触发“send on closed channel”错误；这是运行时不可恢复的崩溃，源于关闭语义为单向终结信号，写入违反通信契约。
向已关闭Channel写入为什么会panic
Go语言规定，向已关闭的chan发送数据会立即触发panic: send on closed channel。这不是运行时警告，而是不可恢复的崩溃——因为关闭后的channel语义上只允许接收，写入违反了通信原语的设计契约。
常见触发场景包括：goroutine未同步退出、select中default分支误写入、或用close()后忘记清空待发数据队列。
用select + default非阻塞检测是否可写
不能靠“判断channel是否关闭”来规避（Go没有公开API检查channel状态），但可以用select尝试非阻塞发送，并用default捕获失败。这本质是试探性写入，不保证成功，但能避免panic。
-
select中仅包含一个case ch 和一个<code>default:分支 - 如果channel已满或已关闭，会立即走
default，不会阻塞也不会panic - 注意：这不能区分“关闭”和“满”，但对多数防御性写法已足够
select {
case ch <- data:
// 成功写入
default:
// ch已关闭 或 已满 —— 此时应丢弃、记录或走降级逻辑
}用recover()兜底不推荐
虽然可以在发送前用defer+recover()捕获panic，但这是反模式：
立即学习“go语言免费学习笔记（深入）”；
- panic是严重信号，代表程序逻辑失控，不应被静默吞掉
- recover只能在同goroutine中生效，而channel写入常发生在并发goroutine里，难以统一拦截
- 一旦recover，你无法知道是哪个channel出问题、谁关的、为什么关——调试成本陡增
真正需要recover的场景极少，比如顶层goroutine守护，而非channel操作本身。
根本解法：控制channel生命周期与写入方可见性
最可靠的方式不是“防写入”，而是让写入方根本不具备向已关闭channel写入的机会：
- 用
sync.WaitGroup或context.Context协调goroutine退出顺序，确保写入goroutine在读取方调用close()前已停止 - 把channel封装进结构体，用
mutex保护closed标志位，对外只暴露带校验的TrySend()方法 - 避免多个goroutine共用同一channel写入端；优先用“单生产者”模型，或改用
chan struct{}做信号通知而非数据传递
channel关闭动作本身廉价，但关闭时机错配才是问题根源——写入逻辑必须和关闭逻辑在同一个控制流里可见、可推理。
