Golang并发错误处理实用技巧

本文深入剖析了Go语言中goroutine并发场景下错误处理的常见误区与最佳实践，明确指出协程内无法直接return error的根本原因，并系统介绍了通过带缓冲channel、sync.WaitGroup和context协同实现安全、可控、可超时的错误传递方案，强调关闭channel、合理设置缓冲容量及统一nil错误处理等关键细节，帮助开发者写出健壮可靠的并发代码。

goroutine 中不能直接 return error

Go 的协程是独立执行的，go func() { ... }() 启动后立即返回，主 goroutine 不会等待它结束，更不会接收它内部的 return err。常见错误是写成这样：

go func() {
    if err := doSomething(); err != nil {
        return err // 编译失败：无法从无返回值函数中 return error
    }
}()

这类写法直接报错。真正可行的是把 error 传出去——通过 channel、共享变量（需加锁）、或回调函数。

用 channel 收集 goroutine 错误最常用

定义一个 chan error，每个 goroutine 执行完把 error 发进去；主 goroutine 用 for range 或带超时的 select 接收。注意：必须关闭 channel，否则 range 会永久阻塞。

• 多个 goroutine 共用一个 chan error，容量建议设为并发数（避免阻塞）
• 即使某 goroutine 成功，也应发 nil（或跳过发送），方便统一处理
• 若使用 range，务必在所有 goroutine 结束后 close(ch)；推荐用 sync.WaitGroup 配合

errCh := make(chan error, 5)
var wg sync.WaitGroup
<p>for i := 0; i < 5; i++ {
wg.Add(1)
go func(id int) {
defer wg.Done()
if err := processItem(id); err != nil {
errCh <- err
return
}
errCh <- nil // 显式发送 nil，便于统计
}(i)
}</p><p>go func() {
wg.Wait()
close(errCh)
}()</p><p>var errors []error
for err := range errCh {
if err != nil {
errors = append(errors, err)
}
}</p>

context.WithTimeout 配合 cancel 可主动中断错误传播

当某个 goroutine 卡住或耗时过长，仅靠 channel 等不到它的 error。这时要用 context.Context 控制生命周期，并让被调函数支持取消。

• context.WithTimeout 返回的 ctx 和 cancel 必须传入 goroutine
• 被调函数（如 http.Do、time.Sleep、自定义函数）需检查 ctx.Err() 并提前退出
• 不要忽略 ctx.Err() —— 它可能等于 context.DeadlineExceeded 或 context.Canceled，这本身就是一种 error

ctx, cancel := context.WithTimeout(context.Background(), 2*time.Second)
defer cancel()
<p>errCh := make(chan error, 1)
go func() {
errCh <- doWithCtx(ctx) // 内部需 select { case <-ctx.Done(): return ctx.Err() }
}()</p><p>select {
case err := <-errCh:
if err != nil && errors.Is(err, context.DeadlineExceeded) {
log.Println("operation timed out")
}
case <-time.After(3 * time.Second):
log.Println("channel hang, but shouldn't happen if cancel works")
}</p>

recover 不该用于常规错误处理

有人试图在 goroutine 里用 defer + recover 捕获 panic 并转成 error 发到 channel。这只能兜底程序崩溃，**不能替代正常 error 返回**。

• panic 是异常场景（如空指针解引用、切片越界），不是业务错误（如“用户不存在”、“网络超时”）
• recover 无法捕获其他 goroutine 的 panic；每个 goroutine 需单独 defer
• 滥用 recover 会让错误路径模糊，掩盖真实问题

真正该做的是：确保业务逻辑用 if err != nil 显式判断，只在第三方库可能 panic 且你无法修改源码时，才在 goroutine 内加一层 recover 做防御。

实际并发错误处理的复杂点不在语法，而在责任边界是否清晰：谁负责发起、谁负责超时、谁负责重试、谁汇总错误、错误是否可重入。这些决策比选 channel 还是 WaitGroup 影响更大。

到这里，我们也就讲完了《Golang并发错误处理实用技巧》的内容了。个人认为，基础知识的学习和巩固，是为了更好的将其运用到项目中，欢迎关注golang学习网公众号，带你了解更多关于的知识点！