首页 > Golang > Go教程

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

来源：Go Language Specification

时间：2026-06-01 22:29:16 240浏览收藏

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

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

Go channel 关闭原则思维导图 — 思维导图：发送方关闭、接收方不抢关、多发送方协调、close 后发送 panic、range 退出和 context 取消。

我记的最简单原则

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

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

close 不是取消

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

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

Go channel 安全关闭流程图 — 流程图：启动 worker、发送结果、WaitGroup 等待、统一 close(out)，最后由 range 自然收尾。

单发送方：发送方关

最简单的是单发送方。生产者写完所有数据后关闭 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 都结束，所以它来关闭。