Go 未消费结果 channel 怎样卡住工作 goroutine

我在把耗时工作封装成“返回一个结果 channel”的函数时，最容易忽略的不是启动 goroutine，而是调用方什么时候停止接收。如果结果 channel 是无缓冲的，接收方一旦因为超时、错误或只取第一个结果就返回，工作 goroutine 仍可能停在最后一条发送语句上，既回收不了，也不会自然结束。

官方文档：https://go.dev/ref/spec#Channel_types

无缓冲 channel 的发送必须等到接收方同时准备好；因此“结果没人消费”不是普通的丢数据，而是发送方可能永久等待。单次结果可以用容量为一的缓冲脱离时序，也可以让发送操作同时监听取消信号。

先看结果发送为何会一直等待

下面的函数把工作放进 goroutine，再通过无缓冲 channel 返回结果。调用方只关心是否超时，超时分支一旦先返回，后面的 resultCh 就找不到接收者。这个发送点就是 goroutine 卡住的位置。

package main

import (
    "context"
    "fmt"
    "time"
)

type result struct {
    value string
    err   error
}

func work() 

这里的关键不是 time.Sleep，而是接收方的生命周期比发送方短。Go 规范把无缓冲 channel 描述为“发送方和接收方都准备好时通信才成功”；所以发送 goroutine 并不会因为主流程返回而自动取消。

这类问题常见于查询、RPC、文件处理或 fan-out 任务：主流程只需要第一个可用结果，或者遇到一个错误就退出，但后台任务仍沿着结果发送路径继续运行。

用 select 让发送方响应取消

如果结果生产时间不可控，发送方不能只写一条裸发送语句。更稳妥的协议是：工作完成后在“把结果交给接收方”和“取消已经到来”之间选择；调用方离开前调用取消函数，发送方就有机会结束。

func work(ctx context.Context) 

发送方响应取消并不等于底层工作一定立刻停止。doWork 自己也要把 ctx 传给数据库、HTTP 客户端或其它支持取消的依赖；否则只能避免结果发送处的泄漏，不能消除底层操作本身的等待。

取消函数要由拥有这次工作生命周期的调用方负责调用，通常写成 defer cancel()。context 包的约定是通过 Done 传播取消，而不是让子任务反过来取消父任务。

只有一个结果时考虑容量为一的缓冲

如果函数只会发送一次结果，且结果已经独立完成，容量为一的 channel 往往更符合接口语义：工作 goroutine 可以把唯一结果放入缓冲区后退出，接收方随后读取即可。

func workOnce(ctx context.Context) 

容量为一只适合“一次发送、一个结果”的场景，例如异步读取单个配置或等待一次 RPC。它不能替代多结果流的消费策略：如果要发送两个以上结果，第二次发送仍可能因为没人读取而阻塞。

另外，缓冲区只能让发送方跨过一个时序间隙；如果结果很大、任务很多，盲目加大容量只是把泄漏从发送阻塞变成内存和排队压力。容量应由接口的结果数量和背压要求决定。

把结果通道的所有权和关闭边界说清楚

我后来会先写清楚三个约定，再决定 channel 是否缓冲：谁创建它，谁负责发送和关闭，调用方是否允许提前停止接收。这样比单纯在发送处加一个 select 更不容易留下新的竞态。

不要让多个 goroutine 都认为自己拥有关闭权，也不要用“接收方关闭 channel”表达放弃。关闭通常表示“不会再有发送”，而放弃消费应该通过取消信号或专门的生命周期协议表达；否则发送方可能向已关闭的 channel 写入并触发 panic。

排查 goroutine 数量持续上涨

遇到 goroutine 数量持续上涨时，我会先围绕阻塞点问三个问题：发送语句有没有对应接收者，接收者是否可能提前返回，发送和底层工作是否都能看到同一个取消信号。不要先把现象归因于调度器或 GC。

1. 先看堆栈中的阻塞行。 如果大量 goroutine 停在 resultCh ，优先检查结果接收边界，而不是继续增加 worker 数量。
2. 对照所有提前返回路径。 超时、错误、首个结果成功和请求断开都可能让消费者离开；每条路径都应该触发取消或继续消费。
3. 确认取消真的传到了发送点。 只有底层函数收到 ctx 还不够，结果发送本身也要在 select 中监听 ctx.Done()。
4. 区分单次结果和结果流。 单次结果可以评估容量一，多结果流则要设计关闭、背压和退出协议。

最后可以把规则压缩成一句话：结果发送方不能假设接收方永远存在。无缓冲 channel 适合需要双方同步的交接；可取消发送适合调用方会提前离开的任务；容量为一适合只交付一次的独立结果。

常见问题

给结果 channel 加缓冲后还需要 context 吗？

通常仍然需要。缓冲只解决结果发送的一个时序点，不能停止已经开始的底层计算，也不能覆盖多结果、超时和请求断开。

发送方应该关闭结果 channel 吗？

如果发送方拥有生产生命周期，并且接收方需要通过关闭判断结束，发送方应在所有发送完成后关闭。单次结果也可以不依赖 range，但所有权仍要明确。

能不能让接收方关闭 channel 表示不再接收？

不建议。关闭表示不会再有发送，接收方通常无法保证其它发送者已经停止；放弃消费应使用取消信号或让发送者可观察的退出协议。