Go中goroutine的panic不会跨协程传播，必须在每个可能panic的goroutine内用defer+recover捕获处理；recover仅在同一goroutine内有效，需注意状态一致性与资源清理。
在 Go 中，协程（goroutine）中发生的 panic 不会自动传播到启动它的 goroutine，也不会终止整个程序，但若未显式 recover，该 goroutine 会静默退出，可能导致资源泄漏、逻辑中断或难以排查的问题。因此，必须在可能 panic 的 goroutine 内部使用 recover 进行捕获和处理。
goroutine 中必须手动 recover
Go 的 panic/recover 机制仅在**同一 goroutine 内有效**。主 goroutine 中的 defer + recover 无法捕获子 goroutine 的 panic。所以每个可能出错的 goroutine 都应自行包裹 defer-recover 逻辑。
- 不要依赖外层 recover 拦截子 goroutine 的 panic
- recover 必须放在 defer 调用的函数中，且该函数不能被内联（可用空参数匿名函数避免编译器优化）
- recover 只有在 panic 正在发生、且尚未返回到 goroutine 栈顶时才有效
基础 recover 模式：defer + 匿名函数
标准写法是用 defer 延迟一个包含 recover 的匿名函数，在 panic 发生后立即捕获并处理。
go func() {
defer func() {
if r := recover(); r != nil {
log.Printf("goroutine panic recovered: %v", r)
// 可选：上报错误、清理资源、重试等
}
}()
// 可能 panic 的业务代码
doRiskyWork()
}()
- recover() 返回 interface{} 类型，通常为 error 或字符串；建议用类型断言进一步判断
- recover 后 goroutine 恢复执行 defer 后面的语句（如果有），但不会回到 panic 发生点
- recover 只能捕获当前 goroutine 的 panic，不能“继续抛出”给其他 goroutine
安全封装：带日志与上下文的 recover 工具函数
为避免重复写 defer-recover，可封装通用 recover 辅助函数，支持传入 context、logger 或回调处理。
立即学习“go语言免费学习笔记（深入）”；
func safeGo(f func(), logger *log.Logger) {
go func() {
defer func() {
if r := recover(); r != nil {
if logger != nil {
logger.Printf("panic in goroutine: %+v", r)
} else {
log.Printf("panic in goroutine: %+v", r)
}
// 可在此处调用 runtime/debug.PrintStack() 输出堆栈
}
}()
f()
}()
}
// 使用示例
safeGo(func() {
panic("something went wrong")
}, log.Default())
- 封装后调用简洁，逻辑隔离清晰
- 可扩展支持 trace ID、metric 上报、告警通知等运维能力
- 注意：不要在 recover 后盲目继续执行关键流程，需评估状态是否一致
recover 后的状态与注意事项
recover 并不等于“错误已解决”。它只是阻止了 goroutine 终止，但程序状态可能已损坏。
- 不要假设 recover 后变量、锁、连接、文件句柄等仍处于可用状态
- 涉及共享资源（如 mutex、channel、数据库连接）时，务必在 recover 后做显式清理（unlock、close、rollback）
- 对不可恢复的 panic（如 nil pointer dereference、slice bounds out of range），recover 后建议记录完整堆栈并优雅退出该 goroutine
- 可结合
runtime/debug.Stack()获取 panic 时的调用栈，辅助定位问题
