Go context.WithCancel 忘记调用 cancel 会怎样：从 goroutine 泄漏到 defer 位置

接口超时后，服务的 goroutine 数还在慢慢上涨，最容易漏看的地方就是 context.WithCancel 的返回值。创建了带取消能力的上下文，却没有在所有路径上调用 cancel，子 goroutine、定时器和下游等待就可能比请求多活一段时间；短请求量一上来，泄漏会变成可见的内存和调度压力。

只要是主动创建的可取消上下文，没有保障在所有执行分支都调用取消函数，就大概率出现goroutine非预期滞留，积累到一定量级就会引发服务雪崩。

先看一个会慢慢变大的请求现场

下面的代码模拟一个请求启动后台工作后提前返回。问题不在 WithCancel 本身，而在于返回的 cancel 没有被保存和调用。

func handle() {
    ctx, _ := context.WithCancel(context.Background())
    go workerLoop(ctx)
    return
}

func workerLoop(ctx context.Context) {
    ticker := time.NewTicker(time.Second)
    for {
        select {
        case 

每次调用 handle 都会留下一个仍在等待的工作循环。没有取消信号时，ctx.Done() 不会关闭，ticker 也没有机会停止。单次请求看不出问题，压测几千次后，runtime.NumGoroutine() 就会留下明显的阶梯。

cancel 的责任和 defer 的位置

正确写法是把取消函数当成资源释放函数处理：创建成功后立刻登记释放动作。这样即使后面出现参数错误、提前返回或下游调用失败，也不会漏掉。

func handle(ctx context.Context) error {
    workCtx, cancel := context.WithCancel(ctx)
    defer cancel()

    go workerLoop(workCtx)
    if err := loadConfig(workCtx); err != nil {
        return err
    }
    return saveResult(workCtx)
}

defer cancel() 不代表后台工作立刻停止，它会在 handle 返回时广播取消信号。workerLoop 必须在 select 中监听 ctx.Done()，并关闭自己创建的 ticker、channel 或其他等待资源。

还有一个容易忽略的边界：如果 goroutine 的生命周期本来就应该覆盖整个进程，就不要为了“形式完整”给它套一个请求级 context。取消责任要和生命周期的所有权一致。

循环里的 defer 为什么会把问题推迟

批量处理时，下面的写法会把每轮的取消动作拖到 processBatch 返回。批次很大或循环内部创建了定时器时，峰值资源会随轮数增加。

func processBatch(parent context.Context, jobs []Job) error {
    for _, job := range jobs {
        itemCtx, cancel := context.WithTimeout(parent, 200*time.Millisecond)
        defer cancel() // 整个批次结束才集中调用
        if err := processOne(itemCtx, job); err != nil {
            return err
        }
    }
    return nil
}

把一轮工作收进小函数，让 defer 在本轮结束：

func processBatch(parent context.Context, jobs []Job) error {
    for _, job := range jobs {
        if err := processOneJob(parent, job); err != nil {
            return err
        }
    }
    return nil
}

func processOneJob(parent context.Context, job Job) error {
    itemCtx, cancel := context.WithTimeout(parent, 200*time.Millisecond)
    defer cancel()
    return processOne(itemCtx, job)
}

这不是语法偏好，而是资源边界：每一轮返回时，超时计时器和相关子上下文就能及时释放。

用三条证据确认是否真的泄漏

不要只凭 goroutine 数上涨就下结论。先让测试重复调用请求，再看数量是否在请求结束后回落：

before := runtime.NumGoroutine()
for i := 0; i  5 {
    t.Fatalf("goroutine still alive: before=%d after=%d", before, after)
}

测试里可以配合 go.uber.org/goleak 检查未退出的 goroutine。线上则抓取 /debug/pprof/goroutine，重点看重复出现的 workerLoop、定时器等待和业务调用栈。若调用栈都停在同一个 select 分支，通常比单看数量更有说服力。

几个常见误区

• 只调用 cancel 不代表 goroutine 会退出，子任务必须监听 Done。
• 只把父 context 传下去，不会自动替代子任务的超时和资源清理。
• 不要在创建 context 后隔很远才写 cancel，分支越多越容易漏。
• 测试环境里的后台 goroutine、HTTP server 和数据库连接也要明确谁负责关闭，否则 goleak 会报出噪声。

相关问题

忘记调用 cancel 一定会造成永久泄漏吗？

不一定。若父 context 很快结束，子 context 也会收到取消；但依赖父 context 结束的时间和所有者，容易让定时器、goroutine 或下游请求多活，不能把这种“可能自动结束”当成清理策略。

cancel 应该由调用方还是被调用函数负责？

通常由创建带取消能力 context 的函数负责。被调用函数只接收 context.Context，不要擅自调用调用方的 cancel；这样所有权和生命周期更清楚。

如何判断 defer 是否放错了位置？

看它绑定的函数作用域。如果一个循环每轮都创建子 context、ticker 或临时文件，而 defer 所在函数要等整个批次结束才返回，就应拆成小函数或显式在本轮末尾释放。

收尾检查

看到 WithCancel、WithTimeout 或 WithDeadline 时，可以顺手问三件事：取消函数是否立刻登记、监听方是否真正处理 Done、循环里的资源是否在本轮结束。再用 goroutine 数、测试检查和 pprof 栈复查一次，基本能把这类“请求结束了但工作还活着”的问题定位清楚。