在Go语言里，channel被用来在多个goroutine之间传递数据。当我们将一个channel关闭之后，它的语义就发生了变化。如果此时还有代码尝试往这个channel里发送数据，运行时并不会默默忽略，而是会直接抛出panic，让程序崩溃。
向已关闭channel发送数据的表现
下面这段示例演示了向已关闭的channel发送数据会发生什么：
package main
import "fmt"
func main() {
ch := make(chan int, 1)
close(ch)
// 向已关闭的channel发送数据，会触发panic
defer func() {
if r := recover(); r != nil {
fmt.Println("捕获到panic:", r)
}
}()
ch <- 10 // 这一行会导致 panic: send on closed channel
fmt.Println("这行不会执行")
}
运行上面的代码，输出通常是：
捕获到panic: send on closed channel
</p>
<h2>为什么这样设计</h2>
<p>Go语言的设计者认为，向已关闭的channel发送数据几乎总是一个编程错误。因为关闭channel意味着发送方已经声明不会再提供新数据，此时还去发送，说明程序逻辑存在问题。为了让错误尽早暴露，运行时选择用panic来终止错误行为。</p>
<h2>和接收操作的对比</h2>
<p>与发送不同，从已关闭的channel接收数据是安全的。如果channel中还有未读取的数据，会先读到那些数据；读完后再次接收，会立刻拿到对应类型的零值，并且第二个返回值（ok）为false。</p>
<pre class=brush:go;toolbar:false>
package main
import "fmt"
func main() {
ch := make(chan int, 2)
ch <- 5
close(ch)
v, ok := <-ch
fmt.Println(v, ok) // 5 true
v, ok = <-ch
fmt.Println(v, ok) // 0 false
}
如何避免误发送
在实际开发中，可以采取以下做法减少此类问题：
- 明确channel的拥有者，只有发送方才负责关闭channel
- 使用context控制goroutine退出，而不是依赖关闭channel来通知停止发送
- 在不确定channel是否关闭时，不要随意发送，可通过额外信号量协调
总结
向已关闭的channel发送数据会引发panic，这是Go语言主动暴露错误的方式。开发者应当理清channel的关闭责任，在并发模型中谨慎处理发送与关闭的时机，必要时配合recover做兜底，但根本解决之道还是规范channel的使用边界。