如何在Golang中处理并发错误_Golang goroutine错误捕获与处理方法_技术教程

goroutine 中 panic 无法被外层 defer 捕获，必须在每个 goroutine 内部用 defer recover() 处理；errgroup.Group 可安全统一管理多 goroutine 错误；channel 发送错误需避免关闭后发送或死锁。

goroutine 中 panic 无法被外层 defer 捕获

在 Go 中，每个 goroutine 有独立的调用栈，panic 只会终止当前 goroutine，且不会传播到启动它的 goroutine。这意味着你在主函数里写 defer recover()，对子 goroutine 内部的 panic 完全无效。

常见错误现象：程序没崩溃，但某 goroutine 静默退出，日志没输出，逻辑中断——你根本不知道它挂了。

必须在每个可能 panic 的 goroutine 内部做 defer recover()
recover() 只在 defer 函数中有效，且仅能捕获当前 goroutine 的 panic
recover() 返回 nil 表示没有 panic 发生，需显式判断

go func() {
    defer func() {
        if r := recover(); r != nil {
            log.Printf("goroutine panicked: %v", r)
        }
    }()
    // 可能 panic 的代码，比如 map 并发写、空指针解引用等
    m := make(map[string]int)
    m["key"] = 42
    delete(m, "key")
    // 注意：这里如果误用未初始化的指针或 channel，就容易 panic
}()

使用 errgroup.Group 统一收集 goroutine 错误

当多个 goroutine 执行任务并需要返回错误时，手动用 sync.WaitGroup + chan error 容易出错（如漏 send、死锁、重复 clos

e）。errgroup.Group 是更安全的选择，它自动等待所有 goroutine 结束，并在任意一个返回非 nil error 时取消其余任务（可选）。

注意：errgroup.Group 的 Go 方法接收的是 func() error，不是无参函数；错误由 group 自动聚合，无需额外 channel。

导入："golang.org/x/sync/errgroup"
默认行为是“首次出错即取消”，可通过 WithContext 控制取消逻辑
若不希望短路（即全部执行完再汇总错误），需自行管理 errgroup.WithContext(context.Background()) 并禁用 cancel

g := new(errgroup.Group)
for _, url := range urls {
    url := url // 避免循环变量复用
    g.Go(func() error {
        resp, err := http.Get(url)
        if err != nil {
            return fmt.Errorf("fetch %s failed: %w", url, err)
        }
        defer resp.Body.Close()
        return nil
    })
}
if err := g.Wait(); err != nil {
    log.Printf("at least one request failed: %v", err)
}

channel 发送错误时的典型 panic 场景

并发中常通过 chan error 收集结果，但若 channel 已关闭或未缓冲且无人接收，send 操作会 panic（send on closed channel 或 deadlock）。这类错误不会触发 recover，除非你把 send 包在 defer-recover 里——但这通常掩盖了设计问题。

正确做法是控制 channel 生命周期：要么用带缓冲 channel 避免阻塞，要么确保发送前 channel 未关闭，或用 select + default 做非阻塞发送。

不要在 goroutine 退出后还往同一 channel 发送
关闭 channel 应由 sender 负责，receiver 不应 close
多个 sender？改用 sync.Once 或统一由某个 goroutine 关闭

errCh := make(chan error, len(tasks)) // 缓冲大小匹配任务数
for _, task := range tasks {
    go func(t Task) {
        err := t.Run()
        select {
        case errCh <- err:
        default: // 避免阻塞，但需确保容量足够
        }
    }(task)
}
close(errCh)
for err := range errCh {
    if err != nil {
        log.Println("task error:", err)
    }
}

context.WithCancel 配合 goroutine 错误传播

当一个 goroutine 出错，你想让其他相关 goroutine 主动退出（比如超时、认证失败、配置加载失败），靠共享变量或 channel 通知容易遗漏。用 context.Context 是 Go 官方推荐方式，尤其配合 context.WithCancel 或 context.WithTimeout。

关键点：所有子 goroutine 必须监听 ctx.Done()，并在收到信号后清理资源、退出；父 goroutine 在发现错误后调用 cancel()。

不要在 goroutine 中直接调用 cancel()，除非你明确知道它是 canceler
ctx.Err() 在 Done() 关闭后才非 nil，需用 select 监听
HTTP server、database query、time.Sleep 等标准库函数都接受 context，优先使用它们的 context 版本

ctx, cancel := context.WithCancel(context.Background())
defer cancel()
go func() {
select {
case <-time.After(5 * time.Second):
cancel() // 主动取消
}
}()
go func(ctx context.Context) {
for {
select {
case <-ctx.Done():
log.Println("worker exiting due to context cancel")
return
default:
// 执行工作
time.Sleep(100 * time.Millisecond)
}
}
}(ctx)

实际中最容易被忽略的是：recover 只对当前 goroutine 有效，且必须写在 defer 里；而错误传播真正可靠的方式不是靠 panic/recover，而是靠显式 error 返回 + context 控制生命周期。别试图用 recover 拦截所有并发异常——它只是兜底，不是主干逻辑。