跳转到主内容
新派编程网 - 新潮编程理念,全新技术课堂!

如何在Golang中处理并发中的错误 Go语言errgroup处理多协程错误

errgroup.Group 更可靠,因其内置“首次错误即终止”与“等待全部完成”的平衡逻辑,避免手动 channel 导致的竞态、死锁、资源泄漏及 panic 漏报;必须用 errgroup.WithContext 初始化并检查 ctx.Err()。 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,任一失败就停”的任务。 立即学习 “ go语言免费学习笔记(深入) ”; 永远从带取消/超时的 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()
做不到任何一项。 go语言参考手册 中文CHM版 Go 是一个开源的编程语言,它能让构造简单、可靠且高效的软件变得容易。本文给大家带来Go参考手册,需要的可以来下载! Go是从2007年末由Robert Griesemer, Rob Pike, Ken Thompson主持开发,后来还加入了Ian Lance Taylor, Russ Cox等人,并最终于2009年11月开源,在2012年早些时候发布了Go 1稳定版本。现在Go的开发已经是完全开放的,并且拥有一个活跃的社区。 Go 语言特色 简洁、快速、安全 并行、有趣、开源 内存管理、v数组安全、编译 下载 参数差异:
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
只负责不让你漏掉第一个错误。

相关文章