recover无法捕获panic几乎总是因调用位置或上下文不符：必须在defer函数内直接调用、仅对同goroutine有效、且panic尚未退出当前栈帧；跨goroutine、非defer调用、间接调用均失效。
recover 无法捕获 panic，几乎总是因为调用位置或执行上下文不符合约束条件，而不是函数本身失效。
recover 必须在 defer 函数中直接调用
这是最常见也最容易忽略的硬性限制。recover 只在 panic 正在传播、且当前 goroutine 尚未退出时有效，而唯一能稳定捕获它的时机，就是 defer 注册的函数执行期间。
-
defer func() { if r := recover(); r != nil { /* 处理 */ } }()✅ 正确：匿名函数内直接调用recover -
defer handleRecover()（其中handleRecover内部调用recover） ❌ 失效：经过一层函数调用后，goroutine 栈帧已变，recover看不到 panic 上下文 -
if r := recover(); r != nil { }写在函数体任意位置（无论 panic 前后） ❌ 恒返回nil：不在 defer 中，永远无意义
recover 只对同 goroutine 的 panic 生效
Go 的 panic 不跨 goroutine 传播。主 goroutine 里注册的 defer + recover，对子 goroutine 中的 panic 完全无效。
- HTTP server 中每个请求在独立 goroutine 执行，中间件里的
defer func() { recover() }()能捕获该请求 handler 的 panic —— 因为它在同一个 goroutine 内 -
go func() { panic("x") }()启动的 goroutine，必须自己包defer+recover，否则 panic 会直接终止该 goroutine，且不通知主 goroutine - 后台日志 goroutine、定时任务 goroutine 等，只要可能 panic，就必须各自配
defer，不能指望外层“兜底”
recover 被多个 defer 干扰或覆盖
多个 defer 按后进先出（LIFO）顺序执行，但只有最内层（即最后注册的那个）recover 能真正拿到 panic 值，其余均返回 nil。
3-Tier Auto-Backup Daily Snapshots, Drive Mirror & Emergency Recovery
下载
三层自动备份：每日时间戳快照、次级硬盘镜像、紧急对话导出。
立即学习“go语言免费学习笔记（深入）”；
- 如果函数开头注册了
defer func() { recover() }()，中间又注册了另一个defer func() { recover() }()，那么后者会先执行并“取走”panic，前者拿到的是nil - 不要在循环里反复写
defer func() { recover() }()：既不会增强捕获能力，还浪费资源、干扰执行顺序 - 参数在
defer声明时求值，比如defer fmt.Println(x)打印的是注册时刻的x，不是 panic 发生时的值 —— 这容易让人误判捕获时机
recover 后状态已损坏，但错误被掩盖
recover 成功只代表程序没崩溃，不代表逻辑可继续。很多“看似捕获成功却出问题”的情况，其实是副作用未清理导致的隐性故障。
- panic 前已向 channel 发送数据、已 close 文件、已修改全局 map ——
recover不会回滚这些操作 - 数据库事务中 panic 后仅
recover而不显式Rollback()，会导致连接泄露或数据不一致 - HTTP handler 中 recover 后若不调用
http.Error(w, ..., http.StatusInternalServerError)，客户端会一直等待超时，而非收到明确失败响应
真正难处理的从来不是 recover 写不对，而是 panic 发生后你不知道哪些变量已被部分更新、哪些资源已泄漏、哪些 channel 已被 close。这时候靠 recover “兜住”反而比直接崩溃更危险。
