Go语言如何在协程中处理并发错误_Golang并发错误捕获与处理方法_网络技术

协程中 panic 无法被外层 defer 捕获，必须在每个 goroutine 内部用 defer/recover 处理；推荐通过 channel 传递 error、用 context 控制超时与取消、用 errgroup 统一管理错误。

协程中 panic 无法被外层 defer 捕获

Go 的 goroutine 是独立的执行流，其内部发生的 panic 不会传播到启动它的主协程或其他协程。这意味着你在主函数里用 defer/recover 完全捕获不到子协程里的崩溃。

典型现象：panic: runtime error: index out of range 直接终止整个程序，哪怕外层有 recover()
根本原因：每个 goroutine 有自己的调用栈和 panic 栈，recover() 只对当前 goroutine 有效
正确做法：必须在每个可能出错的协程内部做 defer/recover

go func() {
    defer func() {
        if r := recover(); r != nil {
            log.Printf("goroutine panic: %v", r)
        }
    }()
    // 可能 panic 的逻辑，比如 slice 越界、nil 指针解引用
    _ = []int{1}[5]
}()

使用 channel 配合 error 类型传递错误结果

当协程需要返回计算结果或错误时，推荐用 chan error 或带 error 字段的结构体通道（如 chan Result），避免靠日志“猜”哪里失败了。

适用场景：多个协程并行请求 API、批量处理文件、数据库批量插入
注意点：channel 必须有缓冲或确保接收方已就绪，否则协程可能阻塞甚至泄露
不要用全局变量或共享 map 存错误 —— 竞态风险高，且难以追踪来源

type Result struct {
    Data string
    Err  error
}
ch := make(chan Result, 10) // 缓冲足够容纳所有结果
go func() {
defer close(ch)
for _, url := range urls {
resp, err := http.Get(url)
ch <- Result{Data: url, Err: err}
}
}()
for r := range ch {
if r.Err != nil {
log.Printf("failed on %s: %v", r.Data, r.Err)
}
}

context.WithCancel + select 处理超时与主动取消时的错误清理

协程不是孤立存在的，常需响应上下文取消（如 HTTP 请求超时、用户中断）。若只依赖 channel 接收，可能错过取消信号，导致资源泄漏或重复错误。

select 中必须包含 分支，并检查 ctx.Err() 判断是超时还是主动取消
在 ctx.Done() 分支里做清理（关闭文件、释放锁、通知下游），而不是直接 return
别在协程里反复调用 ctx.Err() —— 应该用 select 等待它，否则浪费 CPU

ctx, cancel := context.WithTimeout(context.Background(), 3*time.Second)
defer cancel()
go func(ctx context.Context) {
defer func() {
if r := recover(); r != nil {
log.Printf("panic in worker: %v", r)
}
}()
select {
case <-time.After(5 * time.Second):
log.Println("work done")
case <-ctx.Done():
log.Printf("canceled: %v", ctx.Err()) // 输出 context deadline exceeded 或 canceled
// 这里可以关闭连接、释放内存等
}
}(ctx)

error group（errgroup）统一等待与错误聚合

标准库没有内置 error group，但

golang.org/x/sync/errgroup 是事实标准。它解决的是「等所有协程结束，只要一个出错就提前返回」的问题，比手写 sync.WaitGroup + 全局 error 变量更安全、更清晰。

默认行为：第一个非 nil 错误触发 Wait() 返回，其余协程仍运行（除非你传入 ctx 控制生命周期）
若要“任意错误即停止所有”，必须配合 context.WithCancel，并在每个协程中监听 ctx.Done()
注意：eg.Go() 启动的函数签名必须是 func() error，不能直接传带参数的闭包（需显式捕获）

g, ctx := errgroup.WithContext(ctx)
for _, task := range tasks {
    task := task // 避免循环变量复用
    g.Go(func() error {
        select {
        case <-ctx.Done():
            return ctx.Err()
        default:
            return doWork(task)
        }
    })
}
if err := g.Wait(); err != nil {
    log.Printf("at least one task failed: %v", err)
}

实际项目里最易忽略的是 panic 恢复的粒度 —— 很多人只在顶层加 recover，却忘了每个新起的 goroutine 都是新的 panic 边界。还有就是把 error 当日志打完就丢，没走 channel 或 errgroup 回传，导致调用方完全不知道协程是否成功。

# go # golang # go语言 # 栈 # ai # golang并发 # 标准库 # select # Error # 全局变量 # 结构体

相关栏目：【网站优化151355 】【网络推广146373 】【网络技术251813 】【 AI营销90571 】