recover必须在defer函数中调用，否则恒返回nil；它仅在panic传播且当前defer执行时有效，是栈帧快照检查器而非监听器。
recover必须在defer函数里调用，否则恒返回nil
这是最常踩的坑：把recover()写在普通代码块、if分支、甚至main函数顶层，它一定返回nil。因为recover()只在panic正在传播、且当前defer正在执行时才有效——它不是“监听器”，而是“栈帧快照检查器”。
正确结构只有一种：
defer func() {
if r := recover(); r != nil {
// 处理 panic 值
}
}()
- 这个
defer语句必须出现在可能触发panic的代码之前（哪怕只差一行） - 不能写成
if r := recover(); r != nil { }单独一行——没有defer包裹，recover永远失效 - 不能在goroutine外层函数注册
defer去捕获子goroutine的panic，Go的panic是goroutine局部的
每个goroutine都得单独加defer+recover
HTTP handler里起一个go func() { panic("x") }()，外面的defer+recover完全收不到；后台worker没包recover，可能静默退出、连接卡死、事务没回滚。
典型防护方式有三种：
- 在每个goroutine入口手动加
defer func(){}() - 用
errgroup.Group封装并发任务，它的Go()方法会自动recover - 封装
goSafe(func(){})工具函数，统一注入defer+recover
别指望“一次注册，全局生效”——Go不提供跨goroutine异常传递机制。
recover后不能复用已损坏的状态
recover()让程序继续往下跑，但不等于状态安全。越界访问slice后recover，那个slice可能已处于未定义行为边缘；向已close的channel再写入，大概率二次panic。
实操建议：
- recover后立即清理资源（如关闭文件、释放锁），不要复用原变量
- 避免在recover块里继续调用可能依赖损坏状态的函数
- 推荐显式
return或panic新错误，而不是“硬撑”执行后续逻辑 - 如果必须继续，先做状态校验（比如检查
map是否为nil、channel是否closed）
recover返回值是interface{}，不是error
直接把recover()结果当error用，类型断言失败会导致二次panic。打印或记录时，建议用fmt.Sprint(r)或fmt.Sprintf("%v", r)，避免隐式转换风险。
常见错误现象：
- 写
err := recover().(error)，但panic传的是字符串，直接崩溃 - 日志里只记
r，没做fmt.Sprint处理，导致日志输出<nil></nil>或空字符串 - 试图对
recover()结果调用Error()方法，panic：“interface conversion: interface {} is string, not error”
真正可靠的边界不在recover那一刻，而在你是否愿意为恢复后的每一步重新验证状态。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
