Go并发错误处理：errgroup实战指南

本文深入剖析了 Go 中 `errgroup.Group` 在并发错误处理中的核心优势与最佳实践，指出其通过内置“首次错误即终止”与“等待全部完成”的平衡机制，显著优于手动使用 channel 汇总错误——有效规避竞态、死锁、资源泄漏及 panic 漏报等常见陷阱；强调必须始终通过 `errgroup.WithContext`（配合带超时/取消的 context）初始化，并在子协程中主动检查 `ctx.Err()`、妥善处理 panic（需显式 recover 并转为 error 返回），才能真正实现可靠、可控、可观测的并发任务编排，尤其适用于批量 HTTP 请求、多表数据库操作等“全成功才 OK，一错即止”的关键场景。

errgroup.Group 为什么比自己用 channel 汇总错误更可靠

因为 errgroup.Group 内置了“首次错误即终止”和“等待全部完成”的平衡逻辑，而手动用 chan error 容易漏掉 panic、忘记 close、或在多个 goroutine 同时写入时触发竞态（比如两个协程同时往同一个 chan error 发送，但主 goroutine 只读一次）。

常见错误现象：fatal error: all goroutines are asleep - deadlock（channel 没关且没缓冲），或只拿到第一个错误就退出，但其他协程还在跑——资源泄漏、日志混乱、超时失控。

• 它默认使用 context.Background()，但实际中必须传入带超时的 context.WithTimeout，否则出错后整个组卡死
• Go 方法启动协程，Wait 阻塞直到所有协程结束或首个错误返回；不调用 Wait 就无法拿到错误
• 如果某个协程 panic，errgroup 不会捕获——仍需在协程内用 recover 转成 error 返回

如何正确初始化 errgroup 并设置超时

直接 new errgroup.Group{} 是错的——它没上下文控制能力，超时、取消全失效。必须用 errgroup.WithContext。

使用场景：HTTP 批量请求、数据库多表插入、文件并行处理等需要“全成功才 OK，任一失败就停”的任务。

• 永远从带取消/超时的 context 初始化：g, ctx := errgroup.WithContext(context.WithTimeout(context.Background(), 5*time.Second))
• 所有子协程内部必须检查 ctx.Err() != nil，并在循环中及时退出（比如 HTTP 请求前加 if ctx.Err() != nil { return ctx.Err() }）
• 不要把 ctx 直接传给第三方库（如 http.Client）而不设 timeout，否则 errgroup 的超时可能被绕过

g, ctx := errgroup.WithContext(context.WithTimeout(context.Background(), 3*time.Second))
for _, url := range urls {
    url := url // 避免闭包引用
    g.Go(func() error {
        req, _ := http.NewRequestWithContext(ctx, "GET", url, nil)
        resp, err := http.DefaultClient.Do(req)
        if err != nil {
            return err
        }
        defer resp.Body.Close()
        return nil
    })
}
if err := g.Wait(); err != nil {
    log.Println("at least one failed:", err)
}

errgroup.Go 和普通 go func() 的关键区别

errgroup.Go 不是语法糖，它做了三件事：绑定 context 取消传播、串行化错误收集、保证 Wait 能感知到该协程结束。普通 go func() 做不到任何一项。

参数差异：errgroup.Go 接收一个无参、返回 error 的函数；你不能传带参数的函数，也不能忽略返回值——必须显式 return nil 或具体错误。

• 如果函数签名是 func(string) error，必须包装：g.Go(func() error { return doSomething(url) })
• 如果忘了 return，函数末尾隐式返回 nil，看起来“成功”，实则掩盖逻辑缺陷
• 性能影响极小，底层只是把函数存进 slice，然后用 sync.WaitGroup 控制生命周期

为什么 Wait 返回的错误有时是 nil，但实际有协程 panic 了

errgroup 不处理 panic，panic 会直接终止协程，且不会通知 group。结果就是：其他协程继续跑，Wait 在最后一个协程结束后返回 nil，你以为全成功了。

容易踩的坑：在子协程里调用未经校验的第三方方法（比如 JSON 解析、类型断言）、或对空指针解引用，导致静默失败。

• 必须在每个 Go 的函数体最外层加 defer recover：defer func() { if r := recover(); r != nil { err = fmt.Errorf("panic: %v", r) } }()
• recover 后的 error 要赋给闭包外的变量（或通过返回值传出），否则依然丢失
• 别依赖日志打印来发现 panic——日志可能被并发冲掉，或根本没输出到终端

事情说清了就结束。真正难的不是用对 errgroup，而是想清楚哪些错误该传播、哪些该吞掉、哪些该重试——这得看业务，errgroup 只负责不让你漏掉第一个错误。

理论要掌握，实操不能落！以上关于《Go并发错误处理：errgroup实战指南》的详细介绍，大家都掌握了吧！如果想要继续提升自己的能力，那么就来关注golang学习网公众号吧！