recover() 只在 defer 函数体内直接调用时才可能捕获 panic，普通函数中调用恒返回 nil；defer 必须在 panic 前注册且 recover 必须在 defer 直接上下文中，且仅对当前 goroutine 有效。
recover() 在普通函数体里调用永远返回 nil，不是 bug，是 Go 运行时强制设计的约束 —— 它只在 defer 函数体内被直接调用时才可能捕获 panic。
recover() 直接调用恒为 nil
只要不是写在 defer 函数内部，recover() 就只是个普通内置函数，不带任何“恢复能力”。哪怕你把它放在 panic("x") 后面、同一函数里，它也不会生效，因为 panic 已经触发堆栈解退，而该行代码根本不会执行到（panic 会立即中断当前函数）。
-
recover()不是全局监听器，它没有“注册”概念，也不维持状态 - 它的返回值类型是
interface{}，不是error，不做类型断言就无法提取有效信息 - 常见错误：在函数开头写
if r := recover(); r != nil { ... }→ 这行永远不会进 if 分支，r恒为nil
defer 必须在 panic 前注册，且必须是直接调用
defer 是“注册动作”，不是“延迟执行动作”——它在语句出现时就入栈，但函数体要等函数 return 或 panic 时才执行。顺序错一点，整个 recover 流程就失效。
三层自动备份：每日时间戳快照、次级硬盘镜像、紧急对话导出。
- ❌ 错误：
panic("boom"); defer func() { recover() }()→ defer 根本没注册，recover()永远不执行 - ✅ 正确：
defer func() { if r := recover(); r != nil { /* 处理 r */ } }(); panic("boom") - ⚠️ 封装成命名函数也危险：
defer rec()+func rec() { rec2() }+func rec2() { recover() }→recover()不在 defer 直接上下文，返回nil
recover 只对当前 goroutine 中正在传播的 panic 生效
它不是跨 goroutine 的异常兜底机制。子 goroutine panic，父 goroutine 的 defer + recover 完全无感 —— 除非那个 panic 实际发生在父 goroutine 的调用链中（比如实参求值失败）。
- goroutine A 中
go f()，f 内 panic → A 的 defer 不会触发，recover()不起作用 - 但如果
f()是作为参数传给另一个函数，例如fmt.Println([]int{}[10])，这个越界 panic 发生在当前 goroutine（调用方），A 的 defer 才能捕获 - 多个 defer 按 LIFO 执行，
recover()应放在最外层（即最后声明的 defer），否则可能被其他 defer 干扰或覆盖
recover 后程序不会回到 panic 点，而是继续执行 defer 后逻辑
recover 不是“重试”，它只是终止 panic 传播、让函数能正常 return。之后的代码仍会执行，但你必须自己清理资源、决定是否继续或退出。
- recover 后不能假设原逻辑还能安全运行（比如 panic 来自空指针解引用，状态已损坏）
- 常见漏操作：没记录日志、没做类型断言、没赋值给命名返回值，导致“看似恢复成功”，实则掩盖问题
- 不要用 recover 替代 error 处理 —— 它是兜底，不是常规流程
真正容易被忽略的点是：recover 的有效性完全依赖「defer 注册时机 + 调用位置 + goroutine 边界」三者同时满足。少一个，recover() 就只是个返回 nil 的普通函数。写的时候多看一眼 defer 是否在 panic 前、recover 是否在 defer 函数体第一层、是否在正确 goroutine 里 —— 这比写逻辑还关键。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
