Go中goroutine的panic不会自动传播，必须在该goroutine内用defer包裹recover才能捕获；每个关键goroutine需独立处理panic，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语言免费学习笔记（深入）”；
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 触发
