Go channel 消费者无法退出：用 Context 和 goroutine profile 找出泄漏点

Go 里“消费者无法退出”通常不是 channel 本身坏了，而是消费者只有“继续接收”这一条路，没有“请求结束、上游失败或输入完成”的退出条件。排查时先看 goroutine profile 的阻塞栈，再决定由 Context 取消，还是由生产者关闭 channel；不要让消费者为了收尾去关闭自己并不拥有的输入 channel。

最稳妥的组合是：跨函数、跨请求传递 context.Context，在消费者的 select 中监听 ctx.Done()，由生产者在所有发送完成后关闭输出 channel，最后用 goroutine profile 复查栈数量是否收敛。

本文摘要：先定位阻塞点；再补取消分支；最后按 channel 所有权选择关闭方式，并用四种生命周期场景复查。

先分清“正在等待”和“已经泄漏”

一个消费者停在 并不自动代表泄漏：如果它仍然服务于一个未完成的任务，等待可能是正常状态。更可疑的是请求已经返回、上游已经报错，或者 worker 数量只增不减，而对应栈始终停在同一处接收。

可以先给消费者画出三条边界：正常完成时输入何时关闭；异常结束时谁发出取消；启动消费者的函数何时等待它退出。缺少其中任意一条，下面这种写法就可能长期占住 goroutine：

func consume(jobs 

它只认识“jobs 被关闭”。如果发送方因为请求取消而提前返回，却没有关闭该 channel，消费者会永远等下去。关闭输入 channel 也不是通用补丁，因为多个发送者同时存在时，关闭责任不清很容易产生 panic。

跨层取消优先交给 Context

当消费者跟着 HTTP 请求、批处理任务或上游 RPC 一起结束时，Context 更适合传递取消信号。Go 官方文档建议把它沿调用链传下去；Done 是只读取消通道，父 Context 取消后，派生 Context 也会收到信号。

func consume(ctx context.Context, jobs 

这里有两个独立的退出来源：close(jobs) 表示生产者正常完成，ctx.Done() 表示外层不再需要工作。handle 也要接收同一个 Context；只在外层 select 监听取消，而让底层 I/O 继续阻塞，仍可能留下资源。

用 goroutine profile 把泄漏落到具体栈

如果服务开启了 pprof，可以访问 /debug/pprof/goroutine?debug=1 查看可读的 goroutine 栈。没有网络端点时，也可以在受控诊断代码中调用 pprof.Lookup("goroutine").WriteTo 输出文本。重点不是某一次数量，而是重复采样后同一栈是否持续增加，以及栈顶是否卡在 channel receive、channel send 或等待组。

curl -s 'http://127.0.0.1:6060/debug/pprof/goroutine?debug=1' \
  | grep -A8 -E 'consume|chan receive|chan send|WaitGroup.Wait'

看到 consume 不足以证明根因。继续向下看它等待的是哪个 channel，再回到创建点确认：生产者是否能走到 close，取消是否传到该函数，发送端是否也有 ctx.Done() 分支。若只有消费者可取消、生产者仍可能阻塞在无缓冲发送上，泄漏会从接收端转移到发送端。

关闭 channel、取消 Context，怎么选

可以按责任边界做选择，而不是把两者当成互斥替代品：

最后复查四种情况：正常发送完、父 Context 取消、上游中途报错、重复启动后快速停止。每种场景都要能说明谁触发退出、谁等待退出、哪个资源负责关闭。profile 只用于发现仍然活着的栈，不能因为数量下降就跳过业务结果和错误处理检查。

相关问题

消费者可以主动关闭输入 channel 吗？通常不可以。关闭者应是明确拥有发送端和完成状态的生产者或协调者。

Context 已取消，为什么 goroutine 还在？它可能没有监听 Done，或底层操作没有使用带 Context 的 API；从 profile 栈继续定位。

只看 goroutine 数量能确认泄漏吗？不能。需要结合重复采样、稳定栈签名、退出责任和资源是否回收来判断。