第 16 篇：Channel 避坑大全：各种状态下的读写行为

大家好，我是公号「左诗右码」作者 Alex。

上一篇我们深入剖析了 Channel 的底层结构 hchan 和线程安全机制。

今天这一篇，我们来聊聊 Channel 在实际使用中最容易让人“翻车”的地方——不同状态下的行为差异。

很多线上事故（Panic、死锁、Goroutine 泄漏）都是因为对这些行为理解不透彻造成的。面试官也特别喜欢让你填那个经典的“Channel 行为矩阵表”。

话不多说，直接上干货。

1. 一张图看懂 Channel 的所有行为

如果这篇专栏你只能记住一张图，请务必记住下面这张表。这是 Channel 的“九阴真经”。

操作 \ 状态	nil (未初始化)	active (正常/打开)	closed (已关闭)
关闭 (close)	Panic	成功关闭	Panic
发送 (ch <-)	永久阻塞	阻塞(满) / 成功(未满)	Panic
接收 (<- ch)	永久阻塞	阻塞(空) / 成功(有值)	永远不阻塞 (返回零值, false)

记忆口诀（非常经典，建议刻在 DNA 里）：

“空读写阻塞，写关闭异常，读关闭空零”

这 15 个字高度概括了所有的致命陷阱：

空读写阻塞：对 nil（空）的 Channel 进行读、写操作，都会导致永久阻塞。
写关闭异常：向已经 closed（关闭）的 Channel 发送数据，会引发 Panic（异常）；并且重复关闭也会 Panic。
读关闭空零：从已经 closed 的 Channel 读取数据，如果缓冲区已空，永远不会阻塞，而是返回该类型的零值。

2. 深度解析：为什么会这样？

光背表容易忘，我们结合上一篇的 hchan 结构来理解为什么。

2.1 针对 `nil` Channel 的操作

var ch chan int // 此时 ch == nil

读/写 nil channel 都会永久阻塞：
- 源码层面，当检测到 c == nil 时，会直接调用 gopark 让出 CPU，而且没有逻辑会去唤醒它（除非被 select 包裹且有 default 分支）。
- 避坑：一定要 make 初始化 channel，或者配合 select 使用。
关闭 nil channel 会 Panic：
- 源码检测到 c == nil，直接抛出 panic: close of nil channel。

2.2 针对 `closed` Channel 的操作

这是面试中最坑爹的地方。

写 (Send) -> Panic：
- 向一个已关闭的 channel 发送数据，Go 认为这是一个逻辑错误。既然接收方已经被通知“没数据了”，你再发就是不讲武德。
- 错误信息：panic: send on closed channel。
- 场景：多个 goroutine 写同一个 channel，其中一个关了，其他的还在写。
- 解决：谁创建，谁关闭；或者使用 sync.Once 确保只关闭一次；或者使用额外的信号 channel 来协调关闭。
读 (Receive) -> 永不阻塞，返回零值：
- 这是 Go 的设计哲学。关闭 channel 意味着“不会再有新数据了”，但为了防止接收方死锁，它允许你“一直读”。
- 读完缓冲区后的行为：如果缓冲区还有数据，先读完数据；如果缓冲区空了，继续读，会立刻返回该类型的零值。
- 问题：我怎么知道读到的是“真的数据 0”还是“关闭后的零值 0”？

2.3 如何判断 Channel 是否关闭？

使用 “comma, ok” 句式：

x, ok := <-ch
if !ok {
    // channel 已关闭，且缓冲区无数据
    fmt.Println("channel closed")
} else {
    // 正常接收到数据 x
    fmt.Println("received", x)
}

ok == true：读到了正常数据。
ok == false：Channel 已关闭，且缓冲区已空。

3. 实战避坑指南

坑 1：Goroutine 泄漏

场景：你启动了一个 goroutine 去读 channel，但是主流程异常退出了，没有关闭 channel，也没有写入数据。

func leak() {
    ch := make(chan int)
    go func() {
        val := <-ch // 这里的 goroutine 会永远阻塞，因为 ch 没人写也没人关
        fmt.Println(val)
    }()
    // 函数退出，ch 没人管了，上面的 goroutine 泄露
}

后果：这个 goroutine 占用的内存（栈空间，约 2KB 起）永远无法释放。积少成多，OOM（内存溢出）。

坑 2：重复关闭 Channel

场景：多个地方都觉得“我应该负责关闭 channel”。

ch := make(chan int)
close(ch)
close(ch) // panic: close of closed channel

解决：

坚持 One Writer Principle（一个写入者原则）：只有一个 goroutine 负责写入，也由它负责关闭。
如果有多个写入者，不要在写入者中关闭 channel。可以在接收者侧关闭（但这会导致写入 panic），或者使用 sync.WaitGroup 等待所有写入者结束，由主协程关闭。

坑 3：for-range 的陷阱

for range 遍历 channel 是最优雅的写法，它会自动处理“阻塞”和“退出”。

for val := range ch {
    fmt.Println(val)
}
// 代码能走到这里，说明 ch 已经被 close 了

注意：如果发送方忘记关闭 channel，接收方的 for range 会一直阻塞在最后一次循环等待中，导致死锁（如果主协程也在等）或 goroutine 泄漏。

4. 经典面试题：如何优雅地关闭 Channel？

问题：有 N 个发送者，M 个接收者，怎么关闭 Channel 才安全？

核心原则：

不要在接收端关闭 Channel（因为无法知道发送端是否发完了）。
不要在有多个并发发送端的情况下，由任意一个发送端关闭 Channel（因为其他发送端会 panic）。

最佳实践：

场景 A：1 个发送者，M 个接收者

发送者发完数据，直接 close(ch)。接收者通过 comma, ok 或 range 感知关闭。

场景 B：N 个发送者，1 个接收者

接收者不能关。发送者也不能随便关。
引入一个 sync.WaitGroup。每个发送者启动前 Add(1)，退出时 Done()。
启动一个专门的 goroutine 等待 Wait()，等所有发送者都完了，再 close(ch)。

func main() {
    dataCh := make(chan int)
    var wg sync.WaitGroup

    // N 个发送者
    for i := 0; i < 10; i++ {
        wg.Add(1)
        go func() {
            defer wg.Done()
            dataCh <- 1 // 发送数据
        }()
    }

    // 专门的关闭者
    go func() {
        wg.Wait()
        close(dataCh)
    }()

    // 1 个接收者
    for val := range dataCh {
        fmt.Println(val)
    }
}

场景 C：N 个发送者，M 个接收者

最复杂。通常需要引入一个额外的 stopCh 信号通道。
任意一方（通常是接收方或者第三方控制者）想停止时，close(stopCh)。
所有发送者在发送前，利用 select 监听 stopCh。

select {
case ch <- value:
    // 正常发送
case <-stopCh:
    // 收到停止信号，退出
    return
}

总结

Channel 是 Go 并发的瑞士军刀，但也容易伤到手。记住这三点：

Read/Write/Close 对 nil/active/closed 的行为矩阵（背下来！）。
Panic 的两大元凶：写已关闭、重复关闭。
泄漏的根源：阻塞的 goroutine 没人唤醒（通常是因为 channel 没关也没人管）。

搞定这些，Channel 在你手中就从“炸弹”变成了“神器”。