如何在Golang中处理并发panic_Golang recover机制安全处理示例_技术教程

recover 只能在引发 panic 的同一 goroutine 的 defer 函数中调用才有效；跨 goroutine 无法捕获，主 goroutine panic 会终止程序，子 goroutine panic 默认静默退出。

Go 的 recover 只能在 defer 中、且必须在引发 panic 的同一 goroutine 内调用才有效——跨 goroutine 的 panic 无法被其他 goroutine 的 recover 捕获。

goroutine 中的 panic 不会自动传播，也不会被外层 recover 拦截

这是最常踩的坑：启动一个新 goroutine 执行可能 panic 的逻辑，却在主 goroutine 里 defer + recover，结果毫无作用。

每个 goroutine 有独立的调用栈，panic 只终止当前 goroutine
recover() 必须出现在 panic 发生的同一个 goroutine 的 defer 函数中
主 goroutine panic 会导致整个程序退出；子 goroutine panic 默认静默终止（除非启用了 GODEBUG=panicnil=1 等调试标志）

go func() {
    defer func() {
        if r := recover(); r != nil {
            log.Printf("goroutine recovered: %v", r)
        }
    }()
    panic("boom in goroutine")
}()

使用 defer + recover 封装并发任务的标准写法

安全模式是：每个可能 panic 的 goroutine 自己负责 recover，而不是依赖外部统一捕获。

避免在匿名 goroutine 外层套 defer —— 那个 defer 属于启动它的 goroutine，不是目标 goroutine
把 defer recover 逻辑写进 goroutine 内部，或封装为可复用函数如 safeGo
recover 后建议记录日志、清理资源（如关闭 channel、释放锁），但不要盲目“吞掉” panic

func safeGo(f func()) {
    go func() {
        defer func() {
            if r := recover(); r != nil {
                log.Printf("panic recovered in goroutine: %v", r)
                // 可选：上报指标、触发告警、写入错误追踪 ID
            }
        }()
        f()
    }()
}

// 使用
safeGo(func() {
    doRiskyWork() // 可能 panic
})

recover 不能恢复所有类型的崩溃

recover 只对 panic 有效，对运行时致命错误（如 nil pointer dereference、stack overflow、out of memory）无效——这些会直接终止程序。

立即学习“go语言免费学习笔记（深入）”；

nil 指针解引用、切片越界、map 写入 nil、channel 关闭 nil 等，在默认配置下会触发 runtime panic，recover 可捕获
但若程序因 runtime.SetMaxStack 过小导致栈溢出，或 cgo 调用中发生 segfault，则无法 recover
os.Exit()、syscall.Exit()、向已关闭 channel 发送值（非 panic 场景）等也不受 recover 影响

结合 context 控制并发 goroutine 的生命周期与 panic 后行为

recover 只解决“不崩溃”，但不解决“任务是否完成”“下游是否等待”等问题。真实场景中需配合 context 做协同退出。

recover 后，若该 goroutine 是某个长任务的一部分，应通过 ctx.Done() 通知上游放弃等待
不要在 recover 后继续执行可能依赖已破坏状态的逻辑
若 goroutine 持有锁或打开文件，recover 后务必显式释放，否则造成泄漏

func worker(ctx context.Context, ch <-chan int) {
    defer func() {
        if r := recover(); r != nil {
            log.Printf("worker panicked: %v", r)
            // 注意：此处不能直接 return，需确保资源清理
            // 如：close(outChan), mu.Unlock(), file.Close()
        }
    }()
    for {
        select {
        case <-ctx.Done():
            return
        case n := <-ch:
            process(n) // 可能 panic
        }
    }
}

真正难的不是写 recover，而是判断 panic 后的状态是否可信、要不要重试、下游能否容忍部分失败——这些没法靠语法机制自动解决。