Go channel 关闭原则：别让 close 变成并发代码里的隐形炸弹

channel 是 Go 很漂亮的设计，但 close(ch) 一点都不浪漫。谁来关、什么时候关、关了以后谁还会写，这几个问题没想清楚，panic 和 goroutine 泄漏迟早会来。

我在代码 review 里最常拦下的并发问题，不是语法不会写，而是把 close 当成“停止按钮”。这篇就按线上经验讲：哪些 channel 该关，哪些不该关，多发送方怎么收口，以及为什么取消更适合交给 context。

我记的最简单原则

一句话：谁负责发送，谁才有资格关闭。接收方一般不要关闭 channel，因为它不知道还有没有别的发送方。接收方一关，如果发送方晚一步写入，程序直接 panic: send on closed channel。

这个原则不是为了显得严谨，而是为了把所有权说清楚。channel 关闭表达的是“以后不会再有新数据”，只有生产数据的一侧最清楚这件事。

close 不是取消

关闭 channel 只能让接收方知道数据流结束了，它不能取消正在执行的数据库查询、HTTP 请求、文件读取，也不能自动停掉 goroutine。很多泄漏就是因为把 close 当成取消信号，结果下游 I/O 还在跑。

跨函数调用链的退出，我更推荐用 context.Context。数据流结束用 close(out)，任务取消用 ctx.Done()，这两个语义分开后，代码会清楚很多。

单发送方：发送方关

最简单的是单发送方。生产者写完所有数据后关闭 channel，消费者用 for range 自然退出。这个模式清晰、稳定，也最符合 Go 的习惯。

func produce(out chan<- int) {
    defer close(out)
    for i := 0; i < 10; i++ {
        out <- i
    }
}

for v := range out {
    fmt.Println(v)
}

这里的关键不是 defer close(out) 本身，而是 close 放在唯一发送者那一侧。消费者只是读取，不参与关闭。

多发送方：不要抢着 close

多个 goroutine 同时往一个 channel 写时，最危险的写法是每个发送方都尝试关闭 channel。低并发下可能没事，压测一上来就随机 panic。

正确做法是让一个协调者负责关闭。常见写法是 worker 全部退出后，由等待者统一关闭输出 channel。

out := make(chan Result)
var wg sync.WaitGroup

for _, job := range jobs {
    wg.Add(1)
    go func(job Job) {
        defer wg.Done()
        out <- handle(job)
    }(job)
}

go func() {
    wg.Wait()
    close(out)
}()

for r := range out {
    use(r)
}

这段代码的所有权很明确：worker 只发送，不关闭；等待者知道所有 worker 都结束，所以它来关闭。

别用 recover 掩盖 send on closed channel

我见过有人用 recover 包一层，试图把 send on closed channel 吃掉。这不是容错，这是把并发所有权问题藏起来。panic 少了，数据可能也丢了，排查更麻烦。

真正要修的是谁能发送、谁能关闭、什么时候不再发送。并发 bug 靠 recover 压下去，最后经常变成“偶现数据不完整”。

done channel 还能不能用

可以用，但要克制。小范围、局部组件里，一个只关闭不发送值的 done channel 仍然很常见。但一旦跨请求链路、跨服务调用、涉及超时和取消原因，context 更合适。

我自己的习惯是：函数参数传 ctx context.Context；内部局部协作可以用 done；结果流结束才 close result channel。

我的 review 清单

• 这个 channel 的发送方是谁？是不是只有发送方负责关闭？
• 有没有多个 goroutine 可能同时 close 同一个 channel？
• 接收方退出后，发送方会不会卡在写 channel 上？
• 任务取消是不是用 context 表达，而不是滥用 close 数据 channel？
• worker 全部退出后，是否有明确协调者统一 close(out)？
• 有没有用 recover 掩盖 send on closed channel 这种设计问题？

最后说句实在话

channel close 的难点不在 API，而在所有权。你只要能回答清楚“谁生产数据、谁宣布结束、谁负责取消”，大部分并发事故都会少很多。

如果一段代码里你看不出谁该 close，那通常不是需要加一层封装，而是需要先把 goroutine 生命周期和数据流边界画清楚。并发代码越想写得稳，越要把这些朴素问题说清楚。