recover必须在defer中调用才有效，仅当goroutine处于panic状态时在defer函数内调用才可捕获panic，直接调用或跨goroutine均无效，且recover后需手动处理流程而非自动续执行。
recover 必须在 defer 中调用才有效
recover 不是普通函数，它只在 defer 函数执行期间、且当前 goroutine 正处于 panic 状态时才有意义。直接在普通函数体里调用 recover() 永远返回 nil，不会捕获任何 panic。
常见错误写法：
func badExample() {
recover() // 这里永远无效
panic("boom")
}
正确姿势是：必须搭配 defer，且 defer 的函数要能访问到 panic 值：
- 把
recover()放在defer的匿名函数或命名函数内部 - 确保
defer注册在 panic 发生前（即 panic 调用之前） - 不能跨 goroutine 使用：goroutine A panic，goroutine B 的
defer+recover无法捕获
recover 只能捕获本 goroutine 的 panic
Go 的 panic 是 goroutine 局部的，recover 对其他 goroutine 的崩溃完全无感。这导致很多误以为“全局兜底”的尝试失败，比如在 main 函数里 defer recover 却想捕获子 goroutine 的 panic。
立即学习“go语言免费学习笔记（深入）”；
典型陷阱场景：
- 启动一个 goroutine 执行可能 panic 的逻辑，main 里 defer recover —— 无效
- 使用
http.DefaultServeMux或框架（如 Gin/echo）时，handler panic 后 HTTP 连接直接断开，除非框架内部做了 recover（如 Gin 默认 recover 中间件） - 想靠一次 recover 拦住所有错误？不行。每个可能 panic 的 goroutine 都得自己配 defer+recover
若需统一处理子 goroutine panic，得手动封装：
func safeGo(f func()) {
go func() {
defer func() {
if r := recover(); r != nil {
log.Printf("goroutine panicked: %v", r)
}
}()
f()
}()
}
recover 后程序不会自动“恢复执行”，需显式控制流程
recover 的作用只是让 goroutine 从 panic 状态中退出，**不等于继续执行 panic 后面的代码**。一旦 panic 发生，控制权就跳转到 defer 链，原函数后续语句不再执行。
所以别指望这样写：
func wrongResume() {
defer func() {
recover()
}()
panic("fail")
fmt.Println("this never runs") // 永远不会打印
}
合理做法是：在 defer 中拿到 panic 值后，做清理、记录、返回错误或重试逻辑，但主流程必须由你主动安排：
- 不要依赖“recover 后自动续跑”，而是把关键路径拆成可中断+可重入的单元
- 如果函数有副作用（如写文件、发请求），recover 后需判断是否已部分完成，避免重复或遗漏
- HTTP handler 中 recover 后应显式写 response，否则客户端会卡死或收到空响应
不该用 recover 替代错误返回，更不该用于控制流
Go 的哲学是“error is value”。99% 的业务错误（I/O 失败、参数非法、网络超时）应该走 error 返回值，而不是故意 panic 再 recover。滥用 recover 会让调用方无法预判行为，也破坏静态分析和工具链支持。
适合 panic 的场景极少，仅限于：
- 程序无法继续运行的致命状态（如配置严重缺失、初始化失败）
- 断言失败（
x.(T)类型断言失败，且你 100% 确认不该发生） - 内部 invariant 被破坏（如 switch 漏掉 case，且该类型本不该出现）
反过来，这些属于反模式：
- 用 panic 表示“用户输入格式错误”——该返回
fmt.Errorf - 用 recover 模拟 try/catch 做常规分支（如“找不到就新建”）——该用 if err != nil
- 在库函数中随意 panic，强迫调用方加 defer recover —— 库应暴露 error
真正难的不是怎么写 recover，而是判断：这个 panic，到底该不该发生？
