<p>向已关闭的 channel 发送数据会 panic。Go 语言中，对已 close() 的 channel 执行发送操作（ch <- v）将立即引发 panic，而接收操作仍可正常进行直至通道为空。</p>
向已关闭的 channel 发送数据会 panic
Go 语言中，对一个已经 close() 的 channel 执行发送操作（ch ）会立即触发运行时 panic，错误信息为 <code>panic: send on closed channel。这属于不可恢复的致命错误，程序会崩溃，除非被 recover() 捕获——但通常不建议这么做。
为什么设计成 panic 而不是返回错误
channel 关闭语义明确：关闭表示“不再有新值要发”，是生产端的终结信号。接收端可通过 v, ok := 中的 <code>ok 判断是否已关闭；而发送端若还能继续发，就违背了该契约。因此 Go 选择在编译期无法检查的场景下，用运行时 panic 强制暴露逻辑错误。
- 关闭 channel 是单向、不可逆操作，且只能由 sender 执行
- 多个 goroutine 向同一 channel 发送时，无法靠锁或标志位安全避免重复关闭或误发——panic 是最直接的失败反馈
- 与接收端的“优雅退出”不同，发送端无合法理由在关闭后还尝试发送
常见误用场景和规避方式
典型出错模式是：多个 goroutine 并发写 channel，其中一个关闭后，其余仍尝试发送；或在 select + default 分支中未检查 channel 状态就盲目发送。
- 确保只有单一 goroutine 负责关闭 channel（通常是最后一个 sender）
- 用 sync.Once 或原子变量标记“已关闭”，在发送前做条件判断（仅适用于你控制全部 sender 的场景）
- 若需“软关闭”或带缓冲的终止信号，改用额外的
done chan struct{}配合select - 测试时可借助
go test -race检测潜在的并发关闭/发送竞争
简单复现示例
package main
<p>import "fmt"</p><div class="aritcle_card flexRow">
<div class="artcardd flexRow">
<a class="aritcle_card_img" href="/ai/2663" title="靠岸学术"><img
src="https://img.php.cn/upload/ai_manual/001/503/042/69b3bf2c510bf638.jpeg" alt="靠岸学术" onerror="this.onerror='';this.src='/static/lhimages/moren/morentu.png'" ></a>
<div class="aritcle_card_info flexColumn">
<a href="/ai/2663" title="靠岸学术">靠岸学术</a>
<p>一款集翻译，阅读，文献管理于一体的英文文献阅读器</p>
</div>
<a href="/ai/2663" title="靠岸学术" class="aritcle_card_btn flexRow flexcenter"><b></b><span>下载</span> </a>
</div>
</div><p><span>立即学习</span>“<a href="https://pan.quark.cn/s/00968c3c2c15" style="text-decoration: underline !important; color: blue; font-weight: bolder;" rel="nofollow" target="_blank">go语言免费学习笔记（深入）</a>”；</p><p>func main() {
ch := make(chan int, 1)
close(ch)
ch <- 42 // panic: send on closed channel
fmt.Println("unreachable")
}注意：即使 channel 带缓冲且仍有空位，只要已关闭，任何发送都会 panic。缓冲区只影响阻塞行为，不改变关闭后的语义约束。
真正难处理的不是 panic 本身，而是它往往出现在多 goroutine 协作的边界上——那个“谁该关、何时关、关完谁负责”的责任划分，比语法细节更易出错。
