recover必须在defer函数体内直接调用才有效，且defer语句须在panic前注册；脱离该上下文则恒返回nil，无法捕获panic。
defer 语句不是“监听器”，它只是把函数调用压进当前 goroutine 的 defer 栈；panic 只执行已入栈的 defer，所以顺序错一点，recover 就完全失效。
defer 必须写在 panic 前面，否则根本不会注册
这是最常被忽略的前提。defer 语句本身是**立即执行**的（注册动作），但 deferred 函数体要等到函数返回时才执行。如果 panic("x") 写在 defer 前面，那后面的 defer 根本没机会运行注册逻辑，自然也不会在 panic 回溯时被调用。
- ❌ 错误写法：
panic("boom"); defer func() { recover() }()→recover()永远不执行 - ✅ 正确写法：
defer func() { recover() }(); panic("boom")→defer先注册，panic 后触发，才能捕获 - 真实场景中，panic 往往来自下游调用（比如
json.Unmarshal解析非法 JSON），你无法预判在哪一行发生，所以defer必须“守在函数入口”
recover 只在 defer 函数体内直接调用才有效
recover() 不是全局异常处理器，它依赖 panic 正在传播、且尚未退出当前函数这个特殊上下文。脱离 defer 函数体，它就只是个普通函数，恒返回 nil。
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- ❌ 错误写法：
func f() { defer runRecover(); panic("x") }，其中runRecover是独立函数 → 失效 - ❌ 错误写法：
func f() { panic("x"); r := recover() }→r一定是nil，且这行根本不会执行到 - ✅ 正确写法：
defer func() { if r := recover(); r != nil { /* 处理 r */ } }()→recover()必须是 defer 匿名函数体内的直接调用 -
recover()返回的是interface{}，不是error；常见漏操作：没做类型断言、没记录日志、没赋值给命名返回值
多个 defer 按后进先出（LIFO）顺序执行，recover 应放在最外层 defer 中
Go 把 defer 当作入栈操作。后注册的 defer 先执行，这对资源释放很自然（后开的文件先关），但对 recover 来说意味着：必须确保它在 panic 触发后是第一个被执行的 defer，否则可能被其他 defer 干扰或覆盖。
- 示例：
defer fmt.Println("A"); defer fmt.Println("B"); panic("x")→ 输出顺序是B、A，不是 A、B - 若你在
defer fmt.Println("A")里调用了recover()，而defer fmt.Println("B")在它后面注册，那么 B 会先执行 —— 这通常不是你想要的 - 最佳实践：把
recover相关的defer放在函数最开头，让它成为栈底（即最后执行），从而兜住所有后续可能发生的 panic - 注意：如果函数内有多个 panic 路径（如不同
if分支），不能靠分散的 defer，而应统一由一个顶层 defer 覆盖
recover 对 goroutine 隔离，跨 goroutine 无法捕获
recover 只对当前 goroutine 有效。主 goroutine 里的 defer 永远捕获不到子 goroutine 的 panic，哪怕它是在同一个函数里启动的。
- ❌ 错误写法：
go func() { panic("sub") }(); defer func() { recover() }()→ 主 goroutine 的recover()完全无效 - ✅ 正确做法：子 goroutine 要“自救”，必须在自己内部写
defer func() { recover() }() - 典型陷阱：HTTP handler 里起 goroutine 处理耗时逻辑，却只在 handler 函数开头写了
defer recover()→ 子 goroutine panic 仍会导致程序崩溃或静默失败 - 更隐蔽的问题：recover 后没显式处理状态，比如没关闭 channel、没释放锁、没 return，可能导致后续逻辑读到脏数据或死锁
真正难的不是写对语法，而是判断该不该用 panic/recover。比如 nil 指针解引用、数组越界这些 runtime panic，你几乎无法提前预防；但除零、空 map 写入、JSON 解析失败——这些都该用 error 显式处理。recover 捕获到的 panic 值，如果不做类型断言、不转成 error、不记录堆栈，就等于白捕获。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
