recover只能在defer函数中生效，且仅能捕获runtime.panic()引发的panic；对runtime.throw()或fatal错误无效，且无法跨goroutine捕获。
recover 只能在 defer 函数里生效
recover() 不是普通函数，它只在 defer 声明的匿名函数或命名函数内部调用时才有效。直接在函数体里写 recover() 会永远返回 nil，捕获不到任何 panic。
- 错误写法：
recover()写在if分支、循环体或函数开头 —— 完全无效 - 正确写法：必须包裹在
defer func() { ... }()里，且该defer要在可能触发panic的语句之前注册 - 常见疏漏：把
defer放在panic之后，比如先除零再 defer —— 此时 panic 已发生，defer 还没注册，自然无法捕获
recover 能捕获哪些 panic，不能捕获哪些
recover() 只能捕获由 runtime.panic()（包括用户显式调用 panic()）引发的运行时异常；对 runtime.throw() 和 runtime.fatal() 触发的崩溃（如栈溢出、内存耗尽、非法指针解引用等底层致命错误），recover() 完全无能为力，程序会直接终止。
- 能捕获：数组越界、空接口方法调用、手动
panic("xxx")、panic(errors.New(...)) - 不能捕获：
panic: runtime error: invalid memory address or nil pointer dereference（某些情况下可捕获，但非所有 nil 解引用都走 panic 路径）、fatal error: stack overflow、throw: out of memory - 关键判断依据：看 panic 错误信息是否以
panic:开头并伴随完整 goroutine stack trace —— 这类通常可 recover；若直接输出fatal error:或程序静默退出，则不可恢复
recover 后如何安全继续执行
成功调用 recover() 后，当前 goroutine 恢复执行，但要注意：panic 已“消耗”，不能再被二次捕获；原 panic 点之后的代码不会自动重试，需手动处理逻辑分支。
- 必须检查返回值：
err := recover()，若为nil，说明没发生 panic，别误当错误处理 - 不要在 recover 后“假装无事发生”继续用已损坏状态（例如切片越界后仍访问
s[2]） - 典型做法：记录日志 + 返回默认值/错误值 + 清理资源（文件句柄、锁、channel 关闭等）
- 避免在 recover 后再调用 panic —— 除非你明确想把错误向上传递，否则容易掩盖原始上下文
func safeDiv(a, b int) (int, error) {
defer func() {
if r := recover(); r != nil {
fmt.Printf("recover from panic: %v\n", r)
}
}()
if b == 0 {
panic("division by zero")
}
return a / b, nil
}跨 goroutine 的 panic 无法被 recover
每个 goroutine 有独立的调用栈，recover() 只能捕获**当前 goroutine** 中由 panic() 触发的异常。主 goroutine 中的 defer+recover 对子 goroutine 的 panic 完全无效。
立即学习“go语言免费学习笔记（深入）”；
- 子 goroutine panic 未被处理 → 该 goroutine 终止，但主 goroutine 继续运行（除非设置了
GODEBUG=catchpanics=1，不推荐） - 若需统一兜底，应在每个可能 panic 的 goroutine 内部单独加
defer+recover - 注意：goroutine 泄漏风险 —— recover 后未关闭 channel、未释放锁、未关闭文件等，比 panic 本身更难排查
真正容易被忽略的是 panic 的传播边界：它不会跨 goroutine，也不跨 CGO 调用，更不会穿透到系统线程。recover 不是万能兜底，而是一个精确作用于当前函数调用栈末尾的“刹车片”——踩得准才有用，踩歪了反而更危险。
