在 Go 语言里，channel 是 goroutine 之间通信的主要手段，但关闭 channel 这件事如果处理不当，很容易引发 runtime panic。很多初学者以为只要数据发完了随手 close 就行，结果程序跑起来偶尔崩溃，排查起来非常麻烦。其实 channel 的关闭有着明确的语义约束，只有理解这些约束并在结构上做好协调，才能真正安全地关闭它。
为什么乱关 channel 会 panic
Go 的运行时规定，向已经关闭的 channel 发送数据会直接触发 panic，而对已关闭的 channel 重复执行 close 同样会 panic。这意味着如果有一个 goroutine 还在尝试往 channel 里写，另一个 goroutine 却把 channel 关了，写的那一方就会崩掉。更隐蔽的是，多个发送方都认为自己该负责关闭，结果大家都调了一次 close，第二次 close 直接报错。
下面这段代码就演示了一个典型错误：主协程在启动写协程后立刻关闭 channel，而写协程稍后还要发送，程序必然崩溃。
package main
func main() {
ch := make(chan int)
go func() {
// 模拟一点延迟后发送
ch <- 1
}()
close(ch) // 危险：写协程还没发完就被关了
}
从语言规范看，close 内置函数会设置 channel 的关闭标志，之后的发送操作在运行时检查到标志就会抛出 panic。因此安全的首要前提是：明确谁是唯一的发送责任方，并且保证 close 时没有任何发送正在进行或将来会发生。
单一发送者模式：发送方自己关
最简单也最安全的情况是只有一个 goroutine 负责写 channel，其余都是读方。此时由这个唯一的发送者在工作完成后关闭 channel，读取方通过逗号 ok 语法判断通道是否关闭即可，完全不需要读方参与关闭。
示例代码如下，发送协程发完三组数据后自行关闭，主协程循环读取直到 ok 为 false：
package main
import "fmt"
func main() {
ch := make(chan int)
go func() {
for i := 0; i < 3; i++ {
ch <- i
}
close(ch) // 唯一发送者负责关闭
}()
for {
v, ok := <-ch
if !ok {
fmt.Println("channel 已关闭，退出读取")
break
}
fmt.Println("收到:", v)
}
}
这种模式的优点是非常清晰，不需要额外同步原语，也不会出现重复关闭。缺点是它只适用于生产者单一的场景。如果业务里有多台爬虫协程往同一个 channel 吐数据，就不能简单套用。
多发送者场景：用额外信号与 once
当有多个 goroutine 同时往同一个 channel 发送时，谁都不应该直接 close，因为无法保证别人发完了。常见做法是引入一个单独的协调协程，或者利用 sync.Once 确保 close 只执行一次，并通过一个停止信号 channel 通知所有写协程不要再发了。
下面例子用 context 通知写协程退出，等所有写协程结束后，由等待组背后的主逻辑用 once 关闭：
package main
import (
"context"
"fmt"
"sync"
"time"
)
func main() {
ch := make(chan int)
ctx, cancel := context.WithCancel(context.Background())
var wg sync.WaitGroup
var once sync.Once
for i := 0; i < 3; i++ {
wg.Add(1)
go func(id int) {
defer wg.Done()
for {
select {
case <-ctx.Done():
return // 收到停止信号，不再发送
case ch <- id:
}
}
}(i)
}
time.Sleep(100 * time.Millisecond)
cancel() // 通知所有写协程停止
wg.Wait()
once.Do(func() { close(ch) }) // 安全关闭一次
for v := range ch {
fmt.Println(v)
}
}
这个方案里，context 承担了广播退出信号的作用，写协程在退出前不会再往 channel 写，因此 close 时不可能有发送发生。once 则防止了重复关闭。虽然结构稍复杂，但它是多生产者下最稳妥的写法之一。
读方永远不要关 channel
一个常见误区是读取方在发现没数据后就顺手把 channel 关了，这是错误的。读方无法知道是否还有发送方准备写，贸然关闭会让发送方 panic。读方只应通过 v, ok := <-ch 判断状态，或者用 for range 在通道关闭后自然退出。
如果确实需要在“所有人都读完”后做清理，应该由发送方或独立协调者关闭，而不是读协程。下面用表格对比一下不同角色关闭的后果：
| 关闭方 | 前提条件 | 风险 |
|---|---|---|
| 唯一发送者 | 确认不再发送 | 低，推荐做法 |
| 多发送者之一 | 无协调 | 高，重复关闭或写方 panic |
| 读取方 | 不知发送方状态 | 高，发送方可能 panic |
从表格可以看出，角色错配是 panic 的根源。设计管道时就要在架构上固定关闭责任，而不是在运行时靠感觉关。
利用 done channel 做广播退出
除了 context，还可以用普通的 done chan struct{} 来做退出广播。写协程用 select 监听 done，主逻辑在确认所有写协程退出后关闭数据 channel。这种方式在老代码里很常见，逻辑直观。
package main
import "fmt"
func main() {
ch := make(chan int)
done := make(chan struct{})
for i := 0; i < 2; i++ {
go func(id int) {
for {
select {
case <-done:
return
case ch <- id:
}
}
}(i)
}
// 模拟运行后关闭
close(done)
// 此处简化，真实场景应等写协程退出再关 ch
// 下面仅演示读方不关 ch 的原则
_ = fmt.Sprint(ch)
}
注意上面示例为了聚焦 done 机制省略了等待写协程退出的细节，实际工程中一定要配合 sync.WaitGroup 等确保发送彻底停止，再去 close 数据通道。done channel 本身不需要关闭也能被监听，但关闭它可以让多个接收方同时解除阻塞，是个好习惯。
总结与最佳实践
安全关闭 channel 的核心就几条：第一，明确关闭责任，优先让唯一发送者关；第二，多发送者必须用信号加一次关闭机制；第三，读方绝不关通道；第四，关闭前保证无发送操作。把这些规则落到代码结构上，就能避开绝大多数 channel 相关 panic。
写并发代码时，建议在创建 channel 的地方就注释清楚谁是发送者、谁有关闭权。这样后续维护的人不会误关，也更容易做 code review。channel 虽简单，但关闭语义一旦忽视，系统稳定性就会受影响。
Golangchannel关闭goroutine同步修改时间：2026-08-10 13:21:45