Go 并发查询如何只保留一个结果：select 竞争与取消信号的收口

线上聚合接口同时查三家下游，最快的一家已经返回，另外两个 goroutine 却还在继续占连接、写结果。问题不在于“有没有调用 cancel”，而在于每个发送结果的路径是否都能观察取消信号，以及接收方是否把通道的生命周期交给了正确的拥有者。

只保留一个结果时，推荐让接收方创建并取消 context，让每个发送方用带取消分支的 select 写入结果；不要让多个发送方争着关闭结果通道。

先把“只要一个结果”说清楚

这类代码经常出现在缓存、数据库和远程服务的竞速查询里：三个候选源都能给答案，业务只需要第一个有效结果。这里的“第一个”指运行时真正先完成并成功送入结果通道的那个，不是源码里排在最前面的 goroutine。

Go 规范明确说明：如果 select 中有多个通信都可以继续，运行时会从可运行分支中做伪随机选择。因此下面这种写法不会让 result 分支拥有固定优先级：

select {
case value := 

如果 resultCh 和 ctx.Done() 在同一时刻都已就绪，任一分支都可能被选中。业务若要求“已经拿到有效结果就优先返回”，就要把结果是否有效的判断放到接收逻辑里，而不是依赖 case 排列。

三种收口方式，差别在谁负责退出

让发送方直接写结果通道

无缓冲结果通道能让首个接收者和首个发送者握手，但首个结果被接收后，其余发送方会永久等待。改成容量为 1 的通道只能缓解一个后续发送者，不能替代取消信号：多个发送方仍可能把没有价值的结果堆进缓冲区。

首个结果到达后取消其余任务

更实用的组合是容量为 1 的结果通道加 context.WithCancel。容量 1 让首个结果不会因为接收方还没开始读取而卡住；发送方再用 select 同时监听 ctx.Done()，取消后能够放弃发送。

type result struct {
    source string
    value  string
}

func first(ctx context.Context, sources []string) (result, error) {
    ctx, cancel := context.WithCancel(ctx)
    defer cancel()

    results := make(chan result, 1)
    for _, source := range sources {
        source := source
        go func() {
            value, err := query(ctx, source)
            if err != nil {
                return
            }
            select {
            case results 

这里假设 query 本身把 ctx 传给了可取消的下游调用。cancel 不会把已经进入 query 的普通计算强行杀掉；它只是发出关闭 Done 通道的信号，代码必须主动观察这个信号。

由一个协调者统一收集

如果每个任务都要回报错误、统计耗时或支持全部失败后的返回值，可以让一个协调 goroutine 负责收集，主 goroutine只负责决定何时取消。这样更容易处理“一个成功就停”“全部失败才报错”“超时优先”等互相冲突的规则，但代码量也更大。

我更建议的实现边界

对于“首个成功结果”这个窄场景，使用容量为 1 的结果通道、每个发送方的取消感知 select，以及接收方的 defer cancel，通常已经足够。不要在这里加一个“谁先返回谁关闭 results”的约定，因为关闭通道和发送通道是两件不同的事。

一个安全的收口检查可以写成：

value, err := first(ctx, []string{"cache", "replica", "primary"})
if err != nil {
    return fmt.Errorf("first query: %w", err)
}
if value.value == "" {
    return errors.New("empty result is not acceptable")
}

若 query 使用 database/sql、HTTP 客户端或其他支持 context 的 API，应把同一个 ctx 继续向下传递。官方文档强调，取消信号只有沿调用链传到实际操作处，数据库查询或网络请求才有机会提前结束。

三个容易误判的边界

• cancel 不是强制终止。 已经进入不可取消的纯 CPU 循环的 goroutine 仍会运行，必要时要在循环中检查 ctx.Err()。
• 不要重复 close(results)。 只要存在多个发送方，任何一个发送方都无法单独证明“以后不会再发送”；错误的 close 会让并发发送直接 panic。
• 不要把空结果当成功。 先定义有效值和错误，再决定是否触发 cancel，否则最快返回的可能只是一个空壳结果。

常见问题

select 能不能保证先执行成功结果？

不能。多个通信同时就绪时，select 会在可运行分支中选择一个。要保证业务语义，应读取后判断结果是否有效，并为取消和超时设计明确的优先级。

结果通道什么时候应该关闭？

如果接收方只读取一个结果，通常无需关闭结果通道。需要 range 读取直到结束时，再让唯一的协调者负责关闭，避免多个发送方竞争关闭权。

为什么调用 cancel 后 goroutine 数量没有立刻下降？

取消是协作式信号。检查 ctx.Done() 的发送方会很快退出，但阻塞在不支持 context 的调用、锁或纯计算中的 goroutine，需要等调用返回或补上可取消边界。

最后的决策表

真正需要盯的不是“有没有写 cancel”，而是取消之后每条执行路径还会不会继续占资源、发送结果或触发副作用。把这个边界写进测试，竞速查询才不会在低流量时看起来正常、压力上来后却留下成批后台任务。