Go channel 关闭时机完整工作流：生产者收口、消费者退出和 panic 防护

Go 里的 channel 很适合做协程之间的数据流转，但它也有一个常见误区：谁都想关，最后就可能出现 panic: send on closed channel；谁都不关，消费者又可能一直等下去。channel 关闭本身不复杂，真正需要理清的是“关闭责任”和“收尾顺序”。

这篇文章按完整工作流来走：先把边界定清楚，再拆成生产者收口、消费者退出、done 信号、WaitGroup 等待和结果通道关闭几个阶段。读完以后，你可以把它当成处理 Go 并发收尾的固定检查表。

摘要

channel 关闭的推荐原则是：发送方负责关闭，接收方只负责读完退出；多个发送方时，不要让每个发送方各自关闭同一个通道，而是由统一的协调者等待所有发送方结束后再关闭。需要提前停止时，用 done 通知协程退出，再用 sync.WaitGroup 确认所有协程已经收尾。

适合人群

• 正在用 Go 写并发任务、批量处理、队列消费的开发者。
• 遇到过 send on closed channel、协程不退出或程序卡住的问题。
• 想把 channel 关闭从“凭感觉写”变成固定工作流的同学。

目标和边界：关闭 channel 到底要解决什么

先把目标说清楚。关闭 channel 不是为了“释放内存”，而是为了告诉接收方：后面不会再有新数据了。接收方看到通道关闭，才能从 for range 里自然退出，后续清理、统计、返回结果才有明确时机。

全流程总览：谁负责关闭 channel

第一条规则很直接：谁发送，谁负责关闭；谁接收，谁不要关闭。因为只有发送方最清楚后面还会不会继续发送。接收方如果提前关闭，就可能让仍在发送的协程撞到已关闭通道。

如果只有一个生产者，代码通常很简单：生产者写完数据后关闭 jobs，消费者用 range jobs 读到结束。

func produce(jobs chan

这里的检查点是：close(jobs) 只出现一次，并且出现在生产者确认不再发送之后。

阶段一：单生产者场景让发送方关闭

单生产者是最容易落地的场景。我们按“创建通道、启动消费者、发送数据、关闭通道、等待消费者退出”的顺序写即可。

package main

import (
    "fmt"
    "sync"
)

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

    wg.Add(1)
    go func() {
        defer wg.Done()
        for job := range jobs {
            fmt.Println("handle:", job)
        }
    }()

    for i := 1; i 

这段代码的关键动作是把关闭放在主流程发送结束之后。消费者不需要判断额外状态，range 会在通道关闭并且缓冲数据读完后结束。

阶段二：多生产者场景交给协调者关闭

多生产者最容易出错。不要让多个生产者都调用 close(jobs)，否则第一个关闭以后，其他生产者继续发送就会触发 panic。推荐做法是增加一个协调者：先等待所有生产者完成，再统一关闭通道。

jobs := make(chan int)
var producers sync.WaitGroup

for p := 0; p 

这一阶段的检查点是：所有生产者只负责发送和退出，只有等待协程负责关闭 jobs。这样关闭动作就从“多个入口”变成了“一个入口”。

阶段三：用 done 信号处理提前停止

有些任务不是自然跑完，而是收到停止信号后要提前退出。比如批量任务遇到错误、页面请求被取消、服务准备停止。此时不要直接关闭数据通道来“打断”发送方，而是单独准备一个 done 通道作为停止信号。

done := make(chan struct{})
jobs := make(chan int)

go func() {
    defer close(jobs)
    for i := 1; i 

这里的核心是把“停止通知”和“数据流结束”分开。done 用来告诉生产者别再发送，jobs 仍然由生产者自己关闭。职责拆开以后，收尾顺序会清晰很多。

我的推荐工作流：done 信号和 WaitGroup 收尾

真实业务里，通常还有结果通道。推荐工作流是：启动 worker，必要时关闭 done，等待 worker 结束，再关闭结果通道。结果通道不应该由某个 worker 单独关闭，因为其他 worker 可能还在写结果。

func runWorkers(done 

这段代码有两个检查点。第一，worker 只写 results，不关闭 results。第二，只有等待所有 worker 结束的协调者才关闭结果通道。

常见误区

误区一：接收方看到不想读了就关闭通道

接收方不一定知道发送方是否还在发送。接收方提前关闭，会把风险转移给发送方。更稳的做法是给发送方一个 done 信号，让发送方自己停止并关闭数据通道。

误区二：多个协程抢着关闭同一个通道

通道只能关闭一次。多个协程都调用 close，本质上是在抢同一个收尾动作。应该把关闭动作集中到一个协调者。

误区三：关闭结果通道太早

如果某个 worker 处理完自己的任务就关闭结果通道，其他 worker 继续写结果时仍然会触发 panic。结果通道要等所有写入方都退出后再关闭。

速查表

总结

Go channel 关闭可以记住一句话：发送方决定数据是否结束，协调者决定多个发送方何时全部结束。把数据通道、停止信号和结果通道分清楚，再用 WaitGroup 做最终确认，就能避免大多数关闭时机带来的 panic、卡住和协程泄漏问题。