Go errgroup 为什么首个错误后任务仍运行

Go 的 errgroup 在首个任务返回错误后仍看到其他任务运行，并不代表取消失效。WithContext 会取消派生的 Context，但它不会强行终止 goroutine；每个 worker 必须主动检查 ctx.Done()，并从函数返回。Wait 也会等所有已提交的函数结束后才返回。

官方地址：https://pkg.go.dev/golang.org/x/sync/errgroup

先分清 errgroup 的三个时间点

最容易混淆的是“首个错误发生”“Context 被取消”和“goroutine 返回”并不是同一时刻。官方文档说明，WithContext 返回的派生上下文会在某个 Go 函数返回非 nil 错误，或 Wait 返回时被取消；而 Wait 会阻塞到所有函数都返回。

g, ctx := errgroup.WithContext(context.Background())

g.Go(func() error {
    return errors.New("读取配置失败") // 首个错误会触发 ctx 取消
})
g.Go(func() error {
    select {
    case 

所以日志里看到第二个任务在首错后短暂打印，并不能证明它绕过了 errgroup。它可能正好已经进入不可抢占的普通计算，或者根本没有使用派生的 ctx。

让每个 worker 真正听懂取消信号

修复重点不是给 Wait 外面再套一个超时，而是把 ctx 送到实际阻塞点。网络请求、数据库调用、定时等待和 channel 收发都应优先使用带 Context 的 API；自写循环则在每轮或每个批次检查一次：

func consume(ctx context.Context, jobs 

这里的关键是 handle 也接收同一个 ctx。如果它内部又启动 goroutine、调用没有 Context 参数的库，外层取消只能停在函数边界，不能自动深入第三方代码。

三类接线错误会让任务看起来没有停止

还要注意，SetLimit 只限制同时活跃的 goroutine 数量，不会把它变成强制终止器。没有任何任务返回错误时，派生 Context 也会在 Wait 返回时取消，因此不要在 Wait 之后把这个 ctx 当作仍然可用的工作上下文。

用 Wait 验证收尾是否真的完成

检查时按这条顺序走：确认所有 g.Go 都在 Wait 之前提交；确认每个 worker 使用的是 WithContext 返回的 ctx；确认取消分支会 return；最后确认文件关闭、响应体关闭、channel 关闭等动作由 worker 自己负责。只有 Wait 返回后，调用方才可以安全地读取最终错误、汇总结果或释放组级资源。

相关问题

errgroup 能像杀线程一样立即停止 goroutine 吗？

不能。它提供协作式取消，代码必须监听 Context 并主动返回；纯 CPU 长循环也要插入检查点。

为什么只写 g.Go 不写 WithContext 也能拿到错误？

零值 Group 仍会收集并由 Wait 返回首个错误，但没有派生 Context，因此不会通知其他任务停止。

首错后返回 ctx.Err 会不会覆盖原始错误？

Wait 返回的是最先出现的非 nil 错误。取消分支返回的 context.Canceled 通常只是协作退出信号，不应替代真正的首个业务错误。