Go并发编程中panic如何处理_Go并发异常处理方式_技术教程

goroutine 中的 panic 不会传播到主 goroutine，仅终止当前 goroutine；必须在同 goroutine 中用 defer+recover 捕获，且 recover 仅在 defer 中有效；errgroup 需手动 recover 并转为 error；panic 后状态可能不一致，recover 仅为止损非回滚。

goroutine 中的 panic 不会传播到主 goroutine

Go 的并发模型决定了每个 goroutine 是独立的执行单元，panic 发生在子 goroutine 中时，**默认不会中断 main goroutine 或其他 goroutine**，而是直接终止该 goroutine，并打印堆栈（如果未捕获）。这常被误认为“异常消失了”，其实是被静默吞掉了。

没有 recover 的 goroutine panic 会导致该 goroutine 退出，但程序继续运行 —— 容易掩盖逻辑错误或资源泄漏
主 goroutine 的 panic 仍会终止整个程序，行为与其他语言一致
标准库如 http.Serve 内部已对每个 handler goroutine 做了 recover，所以 HTTP 服务不会因单个请求 panic 而崩溃

如何在 goroutine 中安全 recover panic

必须在 panic 发生的同一 goroutine 中调用 recover 才有效。常见写法是用 defer + recover 包裹业务逻辑，且需确保 defer 在 panic 前已注册。

go func() {
    defer func() {
        if r := recover(); r != nil {
            log.Printf("goroutine panicked: %v", r)
            // 可选：上报、清理、重试等
        }
    }()
    // 可能 panic 的代码，例如：
    // json.Unmarshal(nil, &v)
    // slice[100] 索引越界
}()

recover() 只在 defer 函数中调用才有效；在普通函数里调用始终返回 nil
不要在 defer 里直接 log.Fatal 或 os.Exit，否则会强制退出整个进程
recover 后无法“继续执行” panic 发生点之后的代码，只能做清理或降级处理

使用 errgroup.Group 管理多个 g
oroutine 并统一处理 panic

errgroup.Group 本身不捕获 panic，但它提供了一种结构化方式启动 goroutine，并配合手动 recover 实现错误聚合。适合需要等待全部完成或任意失败即中止的场景。

g, ctx := errgroup.WithContext(context.Background())
for i := range tasks {
    i := i // 避免循环变量捕获问题
    g.Go(func() error {
        defer func() {
            if r := recover(); r != nil {
                // 将 panic 转为 error，供 errgroup 返回
                g.Go(func() error {
                    return fmt.Errorf("panic in task %d: %v", i, r)
                })
            }
        }()
        return doTask(ctx, i)
    })
}
if err := g.Wait(); err != nil {
    log.Printf("task group failed: %v", err)
}

不能直接在 g.Go 传入的函数里 recover 后返回 error —— 因为 recover 捕获的是 panic，不是 error
上面示例中，用额外的 g.Go 把 panic 转为 error 是一种可行模式，但要注意避免嵌套 goroutine 泄漏
更稳妥的做法是：所有任务函数内部自行 recover 并返回明确 error，让 errgroup 原生处理

日志与监控中容易忽略的 panic 来源

很多 panic 来自第三方库或隐式调用，比如 template.Execute、json.Marshal、reflect.Value.Interface()，它们在特定输入下 panic，但调用方未必意识到要包一层 recover。

HTTP handler、RPC 方法、定时任务这类长期运行的入口点，建议统一加 recover 模板
测试时用 runtime.GOMAXPROCS(1) 和 go test -race 能暴露部分并发 panic 场景，但无法替代运行时 recover
生产环境应结合 debug.SetPanicOnFault(true)（仅 Linux）辅助定位内存类 panic，但注意它会让某些非法指针访问直接 crash，慎用

真正难处理的不是 panic 本身，而是 panic 发生后状态是否一致 —— 比如 channel 已 send 但未 close，mutex 已 Lock 但没 Unlock。recover 只是止损，不是回滚。