Go context.WithCancel 后 goroutine 仍不退出怎么排查：从 done 通道到泄漏证据

服务收到请求后调用了 cancel()，日志也打印了“任务已取消”，但进程里的 goroutine 数量还是每隔几分钟往上涨。这个现象很容易让人误以为 context 没有生效，实际上 cancel 只负责关闭取消信号，正在运行的 goroutine 必须主动监听 ctx.Done()，而且每一个可能长时间等待的操作都要有退出路径。

调用 context.WithCancel 返回的取消函数，本身不会强制杀掉底层 goroutine，你看到的 goroutine 泄漏，基本都是某一步阻塞操作没接入 ctx.Done() 监听，没有响应取消信号导致的。

先把“取消了但没退出”复现出来

下面的示例模拟一个后台 worker。调用方创建上下文后启动任务，随后取消它；问题在于 worker 只在处理前检查一次状态，进入无限等待后就再也没有机会返回。

package main

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

func badWorker(ctx context.Context) {
    if ctx.Err() != nil {
        return
    }
    for {
        time.Sleep(time.Second)
        fmt.Println("处理一批数据")
    }
}

func main() {
    ctx, cancel := context.WithCancel(context.Background())
    go badWorker(ctx)
    time.Sleep(100 * time.Millisecond)
    cancel()
    time.Sleep(2 * time.Second)
}

这里的 cancel() 确实关闭了取消信号，但 badWorker 没有再次读取 ctx.Done()。如果把 time.Sleep 换成没有超时的网络读取，退出会更难观察。

先确认 goroutine 卡在哪里

不要先凭感觉修改 cancel 的调用位置。给程序加一个临时的 pprof 入口，然后在复现期间抓取 goroutine 栈，证据通常比日志更直接。

import _ "net/http/pprof"

go func() {
    _ = http.ListenAndServe("127.0.0.1:6060", nil)
}()

复现后执行：

curl -s http://127.0.0.1:6060/debug/pprof/goroutine?debug=2

重点看新增 goroutine 是否停在 time.Sleep、通道接收、网络读取或数据库驱动调用上。若多个栈都指向同一个 worker，先记下函数名、创建位置和等待点，再做修复。

三类栈信息对应三种判断

• 停在循环体外的通道接收：大概率漏了 ctx.Done() 分支。
• 反复出现在定时器或休眠调用：需要把固定等待改成可取消计时器。
• 停在 HTTP 或数据库读取：应检查下游是否支持上下文，以及是否配置超时。

让每个阻塞点都能响应取消

修复的核心不是增加更多 cancel()，而是让 worker 在等待数据和等待下一轮时都能同时观察取消信号。

func goodWorker(ctx context.Context, jobs 

如果 handleJob 内部还会访问下游服务，也要把同一个 ctx 传进去。以 HTTP 为例，使用 http.NewRequestWithContext 后，请求取消才有机会打断等待中的响应。

req, err := http.NewRequestWithContext(ctx, http.MethodGet, endpoint, nil)
if err != nil {
    return err
}
resp, err := http.DefaultClient.Do(req)
if err != nil {
    return err
}
defer resp.Body.Close()

修复后用三组证据反向验证

只看到一条“收到取消”日志还不够。把退出验证做成测试或临时检查，才能确认 goroutine 真的结束。

1. 启动 worker，记录基线 goroutine 数量；发送一批任务后调用 cancel()。
2. 等待退出信号，例如由 worker 关闭 stopped 通道，不要用固定睡眠猜测它是否结束。
3. 再次抓取 pprof，确认相同创建路径的 goroutine 不再持续增加，并检查下游请求收到 context canceled。

stopped := make(chan struct{})
go func() {
    defer close(stopped)
    _ = goodWorker(ctx, jobs)
}()

cancel()
select {
case 

常见误区和一张排查清单

context.Background() 不能被取消；如果把它传到深层函数，调用方的取消信号就丢了。另一个常见误区是每轮循环重新创建根上下文，导致任务之间无法共享生命周期。生产代码还要注意：收到取消后不要继续把新任务塞进已经关闭或即将停止的 worker。

• 创建 worker 的函数是否保存并传递了同一个 ctx？
• 所有通道接收、定时等待、网络和数据库操作是否有取消或超时？
• 退出是否有明确的 close、返回值或 wait 信号？
• 修复前后的 goroutine profile 是否能对应到同一个创建路径？

相关问题

调用 cancel 后，ctx.Err() 什么时候有值？

取消信号传播后，ctx.Err() 会返回 context.Canceled；超时或截止时间触发时通常返回 context.DeadlineExceeded。它适合做退出原因判断，不代表 goroutine 已经返回。

worker 应该返回 context.Canceled 还是吞掉它？

由上层区分“主动停止”和“真实失败”时，建议保留并向上返回取消原因；如果取消本来就是正常关闭流程，可以在边界层记录后转换成正常退出。

只给 HTTP 客户端设置超时够不够？

不够。循环本身、通道等待、数据库调用和重试等待都可能卡住；客户端超时只覆盖其中一个下游操作。

小结

排查 goroutine 不退出时，先看实际调用栈，再沿着等待点逐个补上取消路径。context.WithCancel 提供的是协作式停止协议，worker 是否结束，取决于循环、定时器和下游调用有没有认真遵守这个协议。最后用退出信号和 pprof 做反向验证，结果才算闭环。