借助 select 同时处理结果、超时与取消信号

在 Go 里同时等待“任务结果、局部超时、上游取消”，最直接的写法是让三个事件各自对应一个 channel，然后交给同一个 select。结果放进带 1 个缓冲位的结果通道，超时使用可停止的 time.Timer，取消信号使用 ctx.Done()；无论哪一路先返回，都调用派生 Context 的 cancel，通知后台任务尽快退出。

Go 官方并发资料：https://go.dev/doc/effective_go#channels

这个模式解决的是“等待方不再需要结果时，怎样同时结束等待与后台工作”。它不会强行终止 goroutine；真正的前提是底层任务也接收并检查 context.Context。

为什么单纯等待结果会卡住

最简单的并发写法是启动 goroutine，再直接从结果通道读取：

resultCh := make(chan string)
go func() {
    // 中文说明：任务不支持取消，耗时过长时调用方只能一直等待
    resultCh 

问题不只在于“等得久”。当请求已取消、客户端已断开或业务只允许等待 800 毫秒时，接收方仍无法退出。如果接收方后来通过其他方式提前返回，worker 再向无缓冲通道发送结果，还可能永久阻塞。

另一个常见误区是用 Sleep 轮询共享变量。它既增加数据竞争，也把响应取消的粒度绑定到轮询间隔。Go 已经用 channel 表达“事件就绪”，无需额外造一套轮询协议。

select 的最小规则

select 会评估各个通信操作，并在一个可执行的 case 中选择一个。只有一个 case 就绪时执行它；多个 case 同时就绪时，不应假设源码靠前的分支具有优先级；没有 case 就绪且没有 default 时，当前 goroutine 阻塞。

对本文场景，三个信号分别承担不同语义：

完整写法：结果、超时和取消放进一个 select

下面的函数刻意把“局部超时”和“上游取消”分开。这样返回错误时可以明确知道是谁终止了等待。

package task

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

type Result struct {
    Value string
    Err   error
}

func Execute(ctx context.Context, timeout time.Duration) (string, error) {
    // 中文说明：派生 Context 用来把本函数的超时继续传给后台任务
    workCtx, cancelWork := context.WithCancel(ctx)
    defer cancelWork()

    // 中文说明：缓冲为 1，避免接收方提前返回后 worker 卡在发送动作上
    resultCh := make(chan Result, 1)
    go func() {
        value, err := doWork(workCtx)
        resultCh 

生产代码还应在进入函数时校验 timeout > 0。示例把结果通道设为 1 个缓冲位，是为了让 worker 最多发送一次结果后可以退出；如果任务会持续发送多条数据，应该改成流式协议，并让每次发送都同时监听 ctx.Done()。

让后台任务真正停下来

等待函数返回不等于后台工作停止。Go 的取消是协作式的：CancelFunc 只发出信号，不会等待任务退出，也不会从运行时强杀 goroutine。官方 context 文档说明，派生 Context 的 Done 会在主动取消、截止时间到达或父 Context 取消时关闭。

因此，底层调用应该优先选择带 Context 的 API，例如 http.NewRequestWithContext、QueryContext 或项目自己的 Do(ctx, ...)。如果底层函数完全忽略 Context，那么缓冲结果通道只能防止发送方卡死，却不能阻止它继续占用 CPU、连接或锁。

四个容易忽略的边界

1. 多个 case 同时就绪时没有业务优先级

结果到达与取消发生在同一时刻时，不能依赖 case 顺序决定谁先执行。如果业务要求“取消后绝不接受结果”，可以在收到结果后再次检查 ctx.Err()，再决定丢弃还是返回；这是业务规则，不是 select 自带优先级。

2. 读取可能被关闭的结果通道要检查 ok

如果结果通道可能由生产者关闭，接收时应使用双值形式：

select {
case result, ok := 

3. 不要给同一动作叠加两个含义相同的超时

如果上游已经用 context.WithTimeout 设置完整调用预算，当前函数可以只监听 ctx.Done()。只有当“当前阶段的局部等待预算”与“整条请求的总截止时间”确实不同，才同时保留 timer.C 和 ctx.Done()。

4. 循环中复用计时器要重置而不是不断创建

单次等待使用 NewTimer 很清楚。高频循环需要反复等待时，应统一管理一个 Timer，在正确停止和清理旧信号后再 Reset；不要在每轮随手创建新的 time.After，否则资源生命周期和测试行为更难控制。

什么时候只需要两路 select

并不是每个函数都需要三个 case。可以按下面的规则缩减：

• 调用方已提供合适的 deadline：只监听 resultCh 与 ctx.Done()。
• 函数没有上游 Context，但需要本地超时：监听 resultCh 与 timer.C。
• 任务必须长期运行，仅响应关闭信号：监听数据通道与 ctx.Done()。
• 只是尝试一次非阻塞发送或接收：使用 default，但要接受丢弃或稍后重试的语义。

采用检查清单

1. 结果、局部超时和上游取消是否真的代表三个不同事件。
2. 结果通道是否按发送次数设置了足够缓冲，或发送侧也监听取消。
3. 派生 Context 的 cancel 是否在所有返回路径执行。
4. 底层 I/O 和循环是否接收并检查同一个 Context。
5. 超时与取消是否分别返回可判断的错误，是否保留 ctx.Err()。
6. 是否错误假设了 select case 的优先级。
7. 可能关闭的通道是否检查 ok。
8. 高频循环中的 Timer 是否有清晰的停止、清理和复用策略。

把三个信号集中到一个 select 后，代码的重点就从“怎样跳出阻塞”变成“每个退出原因应该返回什么，以及后台任务是否真的收到停止信号”。这正是可维护并发代码与只在演示中能工作的代码之间的差别。

相关问题

select 会优先执行写在最前面的 case 吗？
不会。多个通信分支同时可执行时，不应依赖源码顺序表达优先级。

ctx.Done() 关闭后还能继续读取吗？
可以。关闭后的 channel 会持续可读，因此后续 select 会立即命中该 case。

为什么结果通道通常设置为 1 个缓冲位？
当 worker 只发送一次结果时，一个缓冲位允许接收方先因超时或取消返回，worker 仍能完成发送并退出。

调用 cancel 后 goroutine 会立刻停止吗？
不会。goroutine 必须在 I/O、select 或循环中主动观察 Context 的取消信号并返回。

参考资料

• Effective Go：https://go.dev/doc/effective_go#channels
• context 包：https://pkg.go.dev/context
• Go Pipelines and cancellation：https://go.dev/blog/pipelines
• Go 语言规范 Select statements：https://go.dev/ref/spec#Select_statements