Golang并发错误处理技巧解析

Go并发错误处理需主动设计传递路径：用带错误的channel、errgroup或sync.Once共享错误变量，而非recover捕获panic；核心是将错误作为数据流设计，按场景选择合适机制。

Go 语言中协程（goroutine）本身不支持直接返回错误给调用方，错误无法像同步函数那样自然“冒泡”。因此，并发错误处理的核心不是“捕获 panic”，而是**主动设计错误传递路径**——通过 channel、WaitGroup + 共享变量、或第三方错误收集器（如 errgroup）来集中感知和响应失败。

用带错误的 channel 显式传递结果

最直观的方式是让每个 goroutine 将结果（含错误）发送到同一个 channel。接收方在读取时统一判断 err 是否为 nil。

• 定义结构体：type Result struct { Data interface{}; Err error }
• 启动多个 goroutine，各自执行任务后 send Result{Data: ..., Err: err}
• 主 goroutine 从 channel 接收，if r.Err != nil { handle(r.Err) }；注意及时关闭 channel 或用 sync.WaitGroup 控制结束时机
• 适合任务数量固定、需获取全部结果或首个错误的场景（如并发请求多个 API）

用 errgroup 统一管理并自动传播首个错误

golang.org/x/sync/errgroup 是官方推荐方案，它封装了 WaitGroup 和 error 汇总逻辑，天然支持“任意一个出错即取消其余”语义。

• 创建 eg, _ := errgroup.WithContext(ctx)（传入 context 可实现超时/取消联动）
• 用 eg.Go(func() error { ... }) 启动任务，每个函数必须返回 error
• 调用 eg.Wait() 阻塞等待全部完成，返回第一个非 nil 错误（若无错则返回 nil）
• 内部自动 cancel context，其余 goroutine 可通过 ctx.Err() 检测退出，避免资源泄漏

共享错误变量 + sync.Once 避免重复赋值

当只需知道“是否出错”，不关心具体哪个出错时，可用指针 + sync.Once 实现轻量级错误标记。

• 声明 var firstErr error; var once sync.Once
• 每个 goroutine 执行完后： if err != nil { once.Do(func() { firstErr = err }) }
• 主 goroutine 调用 wg.Wait() 后检查 firstErr 即可
• 注意：此方式不提供上下文取消能力，适合简单聚合型任务（如批量写文件，只要一个失败就整体失败）

不推荐：recover 捕获 goroutine panic

虽然能在 goroutine 内用 defer + recover 拦截 panic，但这属于异常兜底，不是错误处理正途。

• panic 应仅用于真正不可恢复的程序错误（如空指针解引用），而非业务错误（如网络超时、参数校验失败）
• recover 无法跨 goroutine 传播 panic，也不能替代 error 返回机制
• 滥用 recover 会让错误流难以追踪，掩盖真实设计缺陷

基本上就这些。关键不是选哪种技术，而是根据场景明确“错误发生时该做什么”：要继续执行其他任务？立刻停止？记录日志？通知上游？把错误当作数据流的一部分来设计，而不是等它突然出现再补救。