Go context.WithCancel 为什么还会泄漏：defer cancel 与请求生命周期

接口压测时，响应延迟并没有立刻飙高，进程里的 goroutine 数却从几百一路涨到几千。代码已经用了 context.WithCancel，但请求提前返回时，后台查询协程还在等结果，最终把“有 Context”误当成了“会自动结束”。真正决定能否回收的，是谁持有 cancel、什么时候调用它，以及子协程有没有监听 ctx.Done()。

先看清泄漏发生在哪条请求路径

典型问题出在“主请求已经结束，子任务还活着”的分支。比如接口先启动一个后台查询，再等待一个较短的业务超时；超时后直接返回 504，但后台查询既没有收到取消信号，也没有主动退出条件。连续压测后，runtime.NumGoroutine() 只升不降，堆栈里常见的停留点是 channel 接收或网络等待。

func loadProfile(parent context.Context) error {
    ctx, cancel := context.WithCancel(parent)
    _ = ctx
    _ = cancel
    // 子任务如果不读取 ctx.Done()，取消信号没有实际效果
    return nil
}

这里的关键不是变量名，而是取消权的归属。创建者知道请求何时结束，也最适合负责释放；把 cancel 丢给一个无法判断请求状态的深层函数，往往会留下遗漏分支。

时间线：WithCancel 为什么没有自动清理

第一步：调用 context.WithCancel(parent) 后，Go 返回一个派生 Context 和一个取消函数。派生 Context 会在父 Context 取消时结束，也会在主动调用 cancel 时结束，但创建动作本身不会触发取消。

第二步：主函数遇到超时、校验失败或下游错误，提前从 HTTP handler 返回。若这一层没有 defer cancel()，子任务仍拿着派生 Context 继续运行。

第三步：子任务如果只写成 ，即使 Context 已经取消，也没有任何代码把它从等待中唤醒。取消信号存在，但执行路径没有消费它。

所以要把“发出信号”和“根据信号离开”分开检查：前者看 cancel 是否执行，后者看每个阻塞点是否监听 Done。

修复动作：让 cancel 和请求退出绑定

最小修复通常放在创建 Context 的下一行，并让 goroutine 在结果与取消之间做选择：

func queryWithTimeout(parent context.Context) (Profile, error) {
    ctx, cancel := context.WithTimeout(parent, 800*time.Millisecond)
    defer cancel()

    resultCh := make(chan Profile, 1)
    go func() {
        profile, err := queryProfile(ctx)
        if err == nil {
            resultCh 

这里的缓冲容量为 1，是为了让查询完成与主协程退出之间不必互相等待；真正的网络查询仍应把 ctx 传给数据库或 HTTP 客户端。若下游 API 不支持 Context，至少要在自己的等待层增加退出分支，并限制任务并发数。

三个检查点决定修复是否成立

别只用一次请求验证。先用固定并发重复触发超时分支，记录开始前后的 goroutine 数；再等一个完整的超时时间和下游最大响应时间，观察数量是否回到稳定区间。必要时配合 pprof.Lookup("goroutine") 查看堆栈，确认残留协程停在业务等待，而不是测试工具本身。

常见误区：defer cancel 不是所有问题的万能药

如果子协程把任务交给一个不支持取消的第三方库，父函数执行 cancel() 后，库内部线程仍可能继续工作。此时要查它的 API 是否接受 Context、是否有关闭方法，以及是否需要独立的并发上限。

另一个误区是把 cancel 放在成功分支里。这样成功请求能清理，超时、参数错误和下游失败却仍然泄漏。取消动作应覆盖整个函数生命周期，除非 Context 的所有权明确转交给了另一个长期组件。

相关问题

调用 cancel 后，所有 goroutine 都会马上消失吗？

不会。cancel 只是关闭 Done 通知；每个协程要在自己的阻塞点检查它，并完成清理后退出。下游调用也可能需要额外的关闭或超时设置。

为什么父 Context 取消了，子任务还在运行？

常见原因是子任务没有读取 ctx.Done()，或者实际使用的是另一个未关联的 Context。沿着函数参数一路核对 Context 来源最有效。

如何快速确认是不是 goroutine 泄漏？

在相同负载下记录 runtime.NumGoroutine() 和 goroutine profile，等待请求与下游超时窗口结束后再看是否回落。只看单次响应成功不能证明协程已经回收。

收尾检查清单

遇到 Go 服务 goroutine 数持续增长时，先定位哪个请求分支提前返回，再确认 cancel 是否覆盖所有返回路径，最后逐个检查 channel、网络和数据库等待是否有 ctx.Done() 出口。修复后用相同并发和超时条件复测，只有数量回到稳定区间、下游调用也停止，才算真正收口。