Golang并发错误收集方法详解

在 Go 并发编程中，安全、可靠地收集多个 goroutine 的错误远比表面看起来复杂：直接向切片 append 会因竞态导致 panic，而官方并无内置并发错误聚合机制；最稳妥的做法是结合 sync.WaitGroup 与 sync.Mutex 手动加锁保护错误切片，更简洁的方案是使用 errgroup.Group（需注意其默认短路行为和上下文传播陷阱），若需完整错误列表则必须自定义 MultiError 类型或借助成熟库；但真正难点在于确保每个 goroutine 都执行完毕、正确响应 context 取消、妥善 recover panic 并上报错误——稍有疏忽就会出现错误静默丢失、goroutine 泄漏或 WaitGroup 死锁，因此务必配合 context 超时控制、严谨的 defer 调用顺序，并用 -race 检测竞态，才能构建出生产级健壮的并发错误收集逻辑。

用 sync.WaitGroup + sync.Mutex 收集并发错误最稳妥

Go 没有内置的“并发错误聚合”类型，直接往切片里 append 会 panic，因为多个 goroutine 同时写 slice 不安全。必须加锁保护错误收集点。

• 先声明 var mu sync.Mutex 和 var errs []error
• 每个 goroutine 执行完后，用 mu.Lock() → append → mu.Unlock() 写入
• WaitGroup 控制主 goroutine 等待全部完成，再返回 errs
• 别用 append(errs, err) 前不加锁 —— 这是线上 panic 高发点

用 errgroup.Group 更简洁，但要注意上下文取消传播

errgroup.Group 是 Go 官方 golang.org/x/sync/errgroup 提供的工具，自动处理错误短路（第一个非 nil 错误就停止后续任务）和等待，比手写锁干净得多。

• 默认行为是“遇到第一个 error 就 Cancel 全部”，适合强一致性场景
• 如果想等所有任务结束再汇总错误，得用 eg.WithContext(context.Background())，避免父 ctx 被 cancel 干扰
• 注意：传入的函数签名必须是 func() error，不能带额外参数 —— 别硬塞闭包捕获变量，容易引发数据竞争
• 示例：eg.Go(func() error { return doWork(id) })，eg.Wait() 返回第一个 error，但所有 error 其实没暴露出来

想真正拿到全部错误？得自己封装一个 MultiError 类型

标准库和 errgroup 都只返回单个 error，要汇总全部失败信息，必须手动聚合。常见做法是定义一个实现 error 接口的结构体。

• 字段通常含 Errors []error，Error() 方法拼接所有消息（比如用 strings.Join）
• 别直接用 fmt.Errorf("%w", errs) —— %w 只包装单个 error，不是列表
• 第三方库如 github.com/hashicorp/go-multierror 提供了成熟实现，但引入依赖前先确认是否真需要它 —— 简单场景用 slice + 自定义 error 足够
• 注意：如果某个子任务 panic，recover 后需转成 error 再收集，否则会被吞掉

别忽略 goroutine 泄漏和 context 超时对错误收集的影响

并发错误收集失效，很多时候不是逻辑错，而是 goroutine 卡死或 context 提前结束，导致部分任务根本没执行完就被丢弃。

• 每个 goroutine 应该接收 ctx context.Context 参数，并在关键阻塞点（如 HTTP 请求、channel 读写）检查 ctx.Err()
• 用 context.WithTimeout 包一层，避免某个慢任务拖垮整体；超时后它的 error 也会进汇总列表
• 别在 defer wg.Done() 前 panic 或 return —— 否则 WaitGroup 计数不匹配，主 goroutine 永远卡在 wg.Wait()
• 测试时故意让一个子任务 sleep 5 秒 + 主 ctx timeout 设为 1 秒，能快速暴露这类问题

以上就是本文的全部内容了，是否有顺利帮助你解决问题？若是能给你带来学习上的帮助，请大家多多支持golang学习网！更多关于Golang的相关知识，也可关注golang学习网公众号。