Golang协程panic处理技巧

在 Go 中，goroutine 的 panic 不会跨协程传播，若不通过 defer + recover 在其内部主动捕获，将导致协程静默退出、资源泄漏甚至业务逻辑中断；因此每个关键 goroutine 都需独立封装 recover 逻辑，不仅要及时记录完整堆栈并区分 panic 类型（如 bug 与可控异常），还需结合业务决策是否降级、重启或安全退出，同时严格避免在 recover 的 defer 中执行复杂操作或引发二次 panic，以真正提升并发程序的健壮性与可观测性。

在 Go 中，协程（goroutine）里发生的 panic 不会自动传播到主 goroutine，若不显式 recover，会导致该 goroutine 悄悄终止，还可能引发资源泄漏或逻辑中断。要真正保障程序稳定，不能只靠 defer + recover，而需结合场景合理使用。

recover 必须在 defer 中调用才有效

recover 只有在 defer 函数中、且 panic 正在被抛出时调用才有意义。如果写在普通代码流里，或者 recover 调用位置不在 panic 的同一 goroutine 中，它将返回 nil，起不到作用。

• ✅ 正确写法：在 goroutine 内部定义 defer，并在 defer 函数中调用 recover
• ❌ 错误写法：在 main 中 defer recover —— 它无法捕获子 goroutine 的 panic
• ❌ 错误写法：recover 写在 panic 后但没用 defer 包裹 —— 执行不到或无效

每个关键 goroutine 都应独立处理 panic

Go 不支持跨 goroutine 捕获 panic，所以每个可能出错的并发任务都得自己负责错误兜底。常见做法是在启动 goroutine 时就封装好 recover 逻辑。

例如：

go func() {
    defer func() {
        if r := recover(); r != nil {
            log.Printf("goroutine panicked: %v", r)
            // 可选：上报监控、清理资源、重试等
        }
    }()
    // 业务逻辑，可能 panic
    riskyOperation()
}()

recover 后不要忽略错误，要记录并决策是否重启

recover 不是“吞掉错误”，而是获得一次干预机会。简单打印日志往往不够，还需结合业务判断后续动作：

• 记录 panic 堆栈（用 debug.PrintStack 或 runtime/debug.Stack）
• 区分 panic 类型：是预期外的 bug（如空指针），还是可控异常（如超时强制关闭）
• 对可恢复场景（如 HTTP handler），可返回错误响应而非崩溃
• 对长期运行的 worker，recover 后可选择退出、重启 goroutine 或降级执行

避免在 defer 中做复杂操作或再 panic

recover 本身不解决根本问题，若 defer 里又发生 panic（比如日志写入失败、锁冲突），会导致原 panic 丢失，调试更困难。

• 保持 recover 对应的 defer 尽量轻量：只做日志、指标上报、必要 cleanup
• 不要在 defer 中调用可能 panic 的第三方函数（如未加保护的 map 写入、文件 close）
• 如需清理资源，优先用结构化方式（如 sync.Once、对象 Close 方法），而非依赖 recover 触发

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