recover必须在defer中调用才有效，仅在panic发生且goroutine未退出时由defer函数调用才有意义；它只能捕获当前goroutine的panic，返回interface{}需类型断言，且不应替代常规错误处理。
recover必须在defer中调用才有效
直接在普通函数体里写 recover() 永远返回 nil，它只在 panic 正在发生、且 goroutine 尚未退出时，由 defer 延迟执行的函数中调用才有意义。这是最常踩的坑：把 recover() 放错位置，结果 panic 还是冒泡出去了。
正确做法是：在可能触发 panic 的代码外层函数中，用 defer 注册一个匿名或具名函数，并在其中调用 recover()：
func riskyOperation() {
defer func() {
if r := recover(); r != nil {
fmt.Println("捕获到 panic:", r)
}
}()
// 这里可能 panic，比如：
panic("something went wrong")
}
recover只能捕获当前goroutine的panic
Go 的 recover() 是 goroutine 局部的，主 goroutine 里的 defer + recover() 对子 goroutine 中发生的 panic 完全无效。如果你在 go func() { panic(...) }() 里 panic，主流程根本收不到。
- 子 goroutine 必须自己配
defer+recover() - 跨 goroutine 错误传递建议用
errgroup.Group或 channel 显式通知 - 不要指望外层函数“兜底”所有 panic
recover返回值类型是interface{}，需要类型断言才能安全使用
recover() 返回的是 interface{}，但实际值可能是 string、error，甚至自定义结构体（比如某些库 panic 时传入 struct）。直接打印或比较容易 panic（比如对 nil 做类型断言）。
立即学习“go语言免费学习笔记（深入）”；
稳妥做法是先判断非空，再用 switch 或 if v, ok := r.(error) 分支处理：
if r := recover(); r != nil {
switch x := r.(type) {
case string:
log.Printf("panic string: %s", x)
case error:
log.Printf("panic error: %v", x)
default:
log.Printf("panic unknown type: %T, value: %v", x, x)
}
}
recover不是错误处理的常规手段，别用来替代if err != nil
Go 鼓励显式错误检查，panic/recover 应只用于真正异常、不可恢复的场景（如空指针解引用、数组越界、断言失败），而不是业务逻辑中的预期错误（比如文件不存在、网络超时）。
- 滥用
recover会让调用链失去错误上下文，难以调试 - 在 HTTP handler 或 RPC 方法里盲目加 recover，可能掩盖参数校验缺失等问题
- 如果某段逻辑频繁 panic，优先考虑重构——比如用
map[key]value前先if _, ok := m[k]; !ok { ... }，而不是靠 recover 拦住 panic
真正难缠的是那些底层调用（比如反射、unsafe、Cgo）引发的 panic，这时候 recover 才是合理守门人。其他时候，少用，慎用。
