Go 超时后任务还在运行：把 Context 传到真正执行 I/O 的那一层

很多 Go 程序的超时问题并不是 WithTimeout 没生效，而是超时只被最外层看见了：调用方已经返回，真正执行 HTTP、数据库或文件 I/O 的 goroutine 仍没有收到取消信号。解决关键只有一句话：把同一个 Context 传到真正可能阻塞的那一层，并在那里使用支持 Context 的 API 或监听 Done()。

超时返回只代表当前调用不再等待；只有下游工作主动消费 Context，任务才有机会停止。每个派生 Context 都要调用 cancel，结果发送也要保留取消分支。

本文要点：先找出真正阻塞的位置；再沿函数调用链传递 ctx；最后分别处理工作取消、结果发送和错误原因。

先区分超时返回与下游停止

context.WithTimeout 会返回一个派生 Context 和取消函数。deadline 到达时，Done() 会关闭，Err() 通常返回 context deadline exceeded。但 Context 不会强行杀掉 goroutine，也不会自动打断一个完全不认识 Context 的自定义函数。

ctx, cancel := context.WithTimeout(parent, 200*time.Millisecond)
defer cancel()

select {
case 

这段代码只能让当前等待者停止等待。若 workDone 背后的 goroutine 仍在无界循环、阻塞发送或调用不支持取消的 I/O，它依旧会运行。因此排查时不要只看 handler 的返回时间，要顺着调用链找到“最后一个真正接触资源”的函数。

图1：Context 必须穿过业务层，抵达真正执行 I/O 的边界。

把 Context 沿调用链传到 I/O 边界

Go 官方建议把 Context 作为函数第一个参数传递，不要把它塞进业务结构体，也不要用 nil 代替。中间层不需要解释 Context，只要原样向下传；真正的适配层再把它交给 http.NewRequestWithContext、数据库驱动的 QueryContext 等支持取消的接口。

func LoadProfile(ctx context.Context, id string) (Profile, error) {
    req, err := http.NewRequestWithContext(ctx, http.MethodGet,
        "https://api.example.test/profiles/"+id, nil)
    if err != nil {
        return Profile{}, err
    }
    resp, err := http.DefaultClient.Do(req)
    if err != nil {
        return Profile{}, err
    }
    defer resp.Body.Close()
    return decodeProfile(resp.Body)
}

func Handle(ctx context.Context, id string) error {
    _, err := LoadProfile(ctx, id)
    return err
}

这里的边界很明确：Handle 和 LoadProfile 使用同一个 ctx，HTTP 请求也绑定了它。若请求超时，客户端会收到错误；下游是否能及时结束仍取决于具体 I/O 实现，但取消信号至少已经抵达了正确位置。

在阻塞点响应 Done 并返回 ctx.Err

自定义 worker 最容易遗漏两个阻塞点：执行工作时没有检查取消，以及工作完成后向结果 channel 发送时无人接收。两个位置都应使用 select。下面的函数用一个可替换的慢工作示意，但真实项目应让慢工作本身也接收 ctx。

func run(ctx context.Context, in 

不要用“先判断一次 ctx.Err()，再裸写 channel”的组合替代第二个 select，因为判断和发送之间仍可能发生取消。多个发送者场景下，结果 channel 的关闭责任也要由明确的协调者承担，worker 不应互相关闭共享 channel。

图2：阻塞工作和结果发送都要有 Context 取消分支。

用 defer cancel 和原因信息收尾

无论任务最终是成功、主动取消还是 deadline 到达，创建派生 Context 的函数都应尽快调用 cancel。它会释放相关计时器和父子引用；deadline 已经到达也不等于可以省略这次清理。

func slowOperation(ctx context.Context) error {
    ctx, cancel := context.WithTimeout(ctx, 300*time.Millisecond)
    defer cancel()
    return doIO(ctx, "report")
}

如果业务需要知道“为什么取消”，可以使用 context.WithCancelCause，再通过 context.Cause(ctx) 读取原因；普通超时判断仍使用 errors.Is(err, context.DeadlineExceeded)。注意 cancel 只发出停止信号，并不等待 goroutine 退出，所以调用方仍要通过 WaitGroup、结果汇聚或关闭协议确认资源真正收敛。

排查清单：① 超时的 ctx 是否传到了最后一个 I/O 函数；② I/O API 是否真的接收 ctx；③ worker 工作和结果发送是否都监听 Done；④ cancel 是否覆盖所有返回路径；⑤ 是否有明确的 channel 关闭者。

相关问题

只在 handler 外层设置超时够吗？不够。外层可以停止等待，但下游函数必须接收并消费 Context，才能让工作有序退出。

调用 cancel 会立即杀死 goroutine 吗？不会。cancel 关闭取消信号，实际函数要在阻塞点响应它，调用方还应等待必要的收尾。

参考：Go context package、Go Concurrency Patterns: Context。