recover必须在defer函数中直接调用才有效；若在普通函数、中间封装函数或非defer上下文中调用，均返回nil，无法捕获panic。
recover 必须在 defer 中调用才有效
Go 的 recover 只能在 defer 函数里安全捕获 panic，且必须在 panic 发生后、函数真正返回前执行。如果写在普通逻辑分支或单独函数里，recover 会直接返回 nil，起不到作用。
常见错误是把 recover 放在 defer 外面，或者封装成一个“通用 recover 函数”但没在 defer 里调用：
func badExample() {
recover() // ❌ 永远无效，不在 defer 中
defer func() {
// 这里才能起作用
if r := recover(); r != nil {
log.Println("panic caught:", r)
}
}()
}
- defer 是注册机制，不是立即执行；recover 依赖这个执行时机
- 多个 defer 按后进先出顺序执行，recover 应放在最外层（或至少在可能 panic 的操作之后）
- 如果 defer 函数本身 panic，且没再 recover，会导致 panic 向上传播
defer + recover 不能替代资源管理的明确语义
很多人想用 defer + recover 统一兜底释放文件、锁、数据库连接等资源，但这是危险的惯性思维 —— Go 不靠 panic 恢复来管理资源生命周期。
典型问题场景：
立即学习“go语言免费学习笔记（深入）”；
- 打开文件后发生 panic，recover 捕获了，但文件句柄是否已关闭？取决于你有没有在 defer 里显式
file.Close() - 加了
sync.Mutex后 panic，recover 能让程序不崩溃，但锁不会自动释放，下次 goroutine 阻塞在mu.Lock() - 数据库连接未显式
Close()或rows.Close()，recover 完全无感，连接持续泄漏
正确做法是：资源获取和释放配对写在同一个作用域，用 defer 显式关，而不是指望 recover 顺带处理。
OpenClaw 基础设施心跳监控与自动恢复：部署/卸载心跳守护进程，配置主机监控（Gateway、磁盘、内存、CPU、进程），设置飞书告警，自动重启故障Gateway。适用关键词：心跳监控、heartbeat daemon、服务器告警、自动重启、健康检查、auto recovery。
file, err := os.Open("data.txt")
if err != nil {
return err
}
defer file.Close() // ✅ 独立于 panic 是否发生
// 后续可能 panic 的逻辑...
json.NewDecoder(file).Decode(&data) // 可能 panic，但 file.Close 仍会执行
recover 无法捕获 runtime.Goexit 触发的退出
Go 中有两类“非正常退出”：panic 和 runtime.Goexit()。recover 对后者完全无效 —— 它只响应 panic 栈展开过程。
这意味着：如果你在 defer 函数里调用了 runtime.Goexit()（比如某些协程清理逻辑），外面的 recover 看不到任何异常，也不会触发 panic 流程，defer 链照常执行完就退出。
- goroutine 被
Goexit终止时，不会触发外层函数的 panic，因此recover返回nil - 这容易造成误判：“没 panic，所以资源肯定安全”，但实际 goroutine 已静默退出，资源可能滞留
- 尤其在使用
context.WithCancel+select+Goexit的组合时，要额外检查资源是否被主动释放
嵌套 defer 中 recover 的作用域很窄
recover 只能捕获**当前 goroutine**、**当前函数栈帧内**发生的 panic。如果 panic 发生在另一个 goroutine，或发生在 defer 函数调用的子函数中但该 defer 没做 recover，就会逃逸。
例如：
func nestedPanic() {
defer func() {
// 这个 recover 捕不到 go func() { panic("in goroutine") }()
if r := recover(); r != nil {
log.Println(r)
}
}()
go func() {
defer func() {
// ✅ 这里才能捕到
if r := recover(); r != nil {
log.Println("goroutine panic:", r)
}
}()
panic("in goroutine")
}()
}
- 每个 goroutine 需要自己配 defer + recover，不能跨 goroutine 传递或拦截
- recover 不是全局异常处理器，它非常局部化，仅限当前 defer 函数所在栈帧
- 若想统一处理 panic（如日志、指标），需在每处启动 goroutine 的地方显式包装
真正难的不是写对 recover，而是判断哪些 panic 值得 recover、哪些该让程序崩溃、哪些资源根本不能靠 recover 来保全 —— 这些边界往往藏在并发模型和资源所有权转移的细节里。
