Golang标准库context.WithCancel返回的cancel取消函数泄露排查-Golang-PHP中文网

不会直接导致goroutine泄漏，但会间接使监听ctx.done()的goroutine无法退出而持续运行；cancel函数幂等，多次调用无副作用却掩盖逻辑错误；defer cancel()在os.exit、fatal error等场景下不执行。

golang标准库context.withcancel返回的cancel取消函数泄露排查

cancel函数不调用会导致goroutine泄漏吗？

不会直接导致goroutine泄漏，但会间接让依赖该context.Context的逻辑无法及时退出，进而使本该结束的goroutine持续运行。关键点在于：泄漏源头不是cancel本身，而是那些监听ctx.Done()却收不到关闭信号的 goroutine。

context.WithCancel返回的cancel函数本质是向内部 channel 发送一次关闭信号
如果从不调用它，ctx.Done()永远不关闭，监听它的 select 分支永远不会触发
常见于 HTTP handler、定时任务、长连接读写循环中——这些地方若没调用cancel，goroutine 就卡在 select { case 里不动

如何定位未调用的cancel函数？

靠静态分析很难全覆盖，需结合运行时观测和代码约定：

在调用context.WithCancel的位置，强制绑定 cancel 函数到 defer（除非有明确延迟取消逻辑）：
```
ctx, cancel := context.WithCancel(parent)
defer cancel() // 大多数情况应立即 defer
```
使用 go tool trace 观察长期存活的 goroutine，筛选出阻塞在 runtime.gopark 且等待 chan receive 的实例，再反查其 ctx 来源

在测试中启用 context.WithCancel 的 wrapper，记录 cancel 调用状态（仅用于 debug）：

func trackCancel(ctx context.Context) (context.Context, func()) {
  ctx, cancel := context.WithCancel(ctx)
  called := false
  return ctx, func() {
      called = true
      cancel()
  }
}

检查所有 http.HandlerFunc、grpc.UnaryServerInterceptor 等入口处是否漏掉 defer cancel

cancel被多次调用会怎样？

cancel函数是幂等的，多次调用无副作用，但掩盖了逻辑错误：

第二次及之后的调用直接 return，不 panic，也不报错
容易让人误以为“调用了就行”，忽略调用时机和路径覆盖问题
若在不同 goroutine 中并发调用，可能造成竞态误判（虽然函数本身安全，但业务逻辑可能已错乱）

Golang Uber Dig
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等

下载
不要靠“多调几次更保险”来规避问题
每个cancel应有唯一确定的调用点，通常对应一个生命周期终点（如 handler 返回、连接关闭）
避免在 defer 中包裹条件判断来决定是否调用 cancel，这会让调用路径不可靠