Golang errgroup Wait方法中为何需要调用g.cancel()

你之前的认知偏差在于，把context cancel函数的作用局限在了「取消运行中的goroutine」，但实际上cancel的核心职责还包括释放派生context关联的所有占用资源，而且标准库的CancelFunc本身是幂等的，多次调用不会产生任何副作用。

Wait里加这层cancel调用，覆盖了两类Go方法内部cancel逻辑触达不到的必要场景：

• 所有启动的goroutine全部执行成功、无错误返回的场景
• errgroup初始化后，没有启动任何goroutine就直接调用Wait的场景

具体场景示例 #

场景1：全任务正常执行完成无错误 #

举个最常见的业务代码例子：

// 基于服务根context派生errgroup
g, ctx := errgroup.WithContext(serverRootCtx)
// 启动3个并发任务，全部正常执行返回nil
g.Go(func() error {
    // 执行数据库查询，未报错
    return nil
})
g.Go(func() error {
    // 绑定ctx发起HTTP请求，正常返回响应
    return nil
})
g.Go(func() error {
    // 注册了ctx.Done()的回调监听，任务正常跑完没触发取消
    return nil
})

if err := g.Wait(); err != nil {
    return err
}
// 后续还有其他业务逻辑要持续运行

如果Wait方法里不主动调用cancel，这个errgroup派生的子context关联的所有资源（包括父context上注册的取消回调链、内部定时器、相关监听goroutine），会一直等到父context（这里是整个服务生命周期才会取消的serverRootCtx）触发取消才会释放，直接造成资源泄漏，服务长时间运行后会出现内存、goroutine数持续异常上涨的问题。

场景2：errgroup初始化后未启动任何任务就调用Wait #

这种场景在加了前置校验的代码里很常见：

g, ctx := errgroup.WithContext(context.Background())
// 前置参数校验不通过，直接跳过所有任务启动逻辑
if req.ParamInvalid() {
    // 直接调用Wait返回
    return g.Wait()
}
// 校验通过才会启动goroutine执行任务
g.Go(func() error {
    // 任务逻辑
    return nil
})

这种情况下Go方法从来没被调用过，内部的错误触发cancel逻辑完全不会执行，如果Wait里不补cancel调用，刚初始化派生的context资源会直接泄漏。

至于你提到的「任务出错时Go方法已经调用过cancel」的场景，因为CancelFunc多次调用是安全无副作用的，Wait里再调用一次不会产生任何问题，只是做了一层兜底。

内容的提问来源于stack exchange，提问作者Drake