Go 中如何让超时请求真正停止：context.WithTimeout 与 goroutine 退出边界

线上任务最容易留下的并不是“超时返回”本身，而是超时后仍在后台运行的 goroutine。Go 的 context.WithTimeout 会让派生 Context 在截止时间到达时关闭 Done，但它不会强行打断一段不检查取消信号的普通计算。要让请求真正停下来，调用链必须把 Context 传到底层，并让每个可阻塞或可循环的工作点处理 ctx.Done()。

超时是取消信号，不是线程终止器；只有 worker 主动监听 ctx.Done() 并返回，goroutine 才会结束。

WithTimeout 到 worker：取消信号怎样走完整条调用链

WithTimeout 返回一个派生 Context 和一个取消函数。它的截止时间取父 Context 与本次 timeout 中更早的那个；调用方应释放 cancel。真正的关键在 worker：它不能只接收一个没有 Context 的函数，而要明确接收 ctx。

package main

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

func worker(ctx context.Context, wg *sync.WaitGroup, out chan

这段程序里，main 创建超时 Context，worker 读取它的 Done，取消时写入 ctx.Err() 后立即返回；WaitGroup 再关闭结果通道。可见成功状态不是“收到一次 timeout 字符串”，而是结果通道最终关闭且 worker 已经执行了 return。

循环和阻塞点都要有退出分支

最常见的误区是只在函数入口检查一次 ctx.Err()。如果后面进入长循环，或者卡在 channel、定时器和外部调用上，入口检查并不能让它及时退出。把取消分支放进每次工作选择的位置，才能缩短退出延迟。

func consume(ctx context.Context, jobs 

这里有三条真实路径：Context 取消时返回取消原因，jobs 正常关闭时返回 nil，收到任务后调用 handle。如果 handle 自身还会等待数据库、RPC 或文件操作，也应继续接收并传递 ctx；否则上层返回了，底层工作仍可能继续。

为什么 defer cancel 仍然必不可少

超时到了以后，派生 Context 会被取消，但“最终会超时”不是不调用 cancel 的理由。调用方提前完成、提前失败或切换到另一个结果时，仍需要主动结束计时器和派生 Context 的资源关联。把 defer cancel() 放在创建 Context 的同一层，代码审查时也更容易确认所有出口都覆盖。

另一个边界是父 Context。若请求 Context 先被客户端断开而取消，子 Context 会一并取消；因此后台任务若确实不应随请求结束，不能随意把它伪装成请求内工作，而应显式设计独立生命周期并承担相应的回收责任。

用可观测结果验收 goroutine 是否真的退出

不要只看日志里打印了“timeout”。测试时可以让 worker 在 return 前发出一次完成信号，再等待它关闭。若测试超时，通常意味着某个循环、通道读取或底层调用没有接收 Context。

func TestWorkerStops(t *testing.T) {
    ctx, cancel := context.WithCancel(context.Background())
    done := make(chan struct{})
    var wg sync.WaitGroup
    wg.Add(1)
    go func() {
        defer wg.Done()
        defer close(done)
        for {
            select {
            case 

这个测试的成功状态是 wg.Wait() 返回，并且 done 已关闭；它验证的是 goroutine 生命周期，而不只是 Context 的错误值。

常见问题：超时取消的几个边界

调用 cancel 后，正在执行的普通 CPU 计算会被抢停吗？

不会。普通 Go 代码必须在循环或阶段边界主动检查 ctx.Done()；可取消的 I/O API 则应接收 Context。

ctx.Err() 什么时候有值？

Context 被取消或截止时间到达后，Err() 才会返回取消原因；在此之前通常返回 nil。

只把 Context 放在最外层够吗？

不够。每一层都应把 ctx 继续传给会等待、循环或调用外部依赖的下一层，否则取消信号会在调用链中断掉。

小结

一条可靠的超时链应同时具备四件事：边界处创建并释放 Context，函数签名显式接收 ctx，工作点监听 ctx.Done()，测试等待 worker 退出。把“超时返回”和“后台 goroutine 已结束”分开验证，才能避免只修复了表面响应时间，却把工作留在进程里。