recover必须写在defer中且defer需在panic前声明，仅在panic状态下的defer执行时有效；panic不可替代error，仅用于真正异常场景；子goroutine panic无法被外层recover捕获；recover后不可继续使用可能已损坏的数据。
recover 必须写在 defer 里，否则永远拿不到 panic 值
很多人写 recover() 时直接放在函数体里，比如在 panic() 后面加一行 r := recover() —— 这完全无效，recover() 会返回 nil，程序照样崩溃。它只在 defer 执行阶段、且当前 goroutine 正处于 panic 状态时才“被运行时注入”真实值。
- ✅ 正确姿势：用
defer func() { if r := recover(); r != nil { /* 处理 */ } }()包裹 - ❌ 错误姿势：
panic("boom"); r := recover()（这行根本执行不到） - ⚠️ 注意顺序：
defer语句必须出现在panic触发之前（语法上靠前），否则注册来不及 - ? 小技巧：把 recover 封装成通用函数，比如
safeRun(func() { ... })，避免每个地方重复写 defer
panic 不是 error 替代品，90% 的业务错误不该用它
Go 社区明确反对用 panic 处理可预期的失败，比如参数校验不通过、数据库查不到记录、HTTP 返回 404——这些都该走 error 返回路径。滥用 panic 会让调用方无法判断哪些错误能恢复、哪些该重试、哪些要告警。
- ✅ 合理用法：程序启动时配置文件缺失、关键全局变量初始化失败、断言某个绝对不该为
nil的指针为空 - ❌ 反模式：
if userID == 0 { panic("invalid user ID") }→ 应该返回errors.New("invalid user ID") - ⚠️ 风险：recover 后你拿到的是一个“已中断的执行现场”，对象状态可能半更新、锁没释放、事务没回滚——别指望继续跑完后续逻辑
子 goroutine 的 panic 永远不会被外层 recover 捕获
这是最常被忽略的并发陷阱。主 goroutine 里写了 defer recover()，但启动的 go func() { panic(...) }() 崩溃了，主流程完全感知不到，那个 goroutine 就静默死了。
- ✅ 正确做法：每个可能 panic 的 goroutine 内部自己加
defer recover() - ✅ 推荐封装：
go func() { defer safeRecover(); doWork() }() - ❌ 错误假设：“我在 main 函数 defer 了一次，所有协程都受保护”
- ? HTTP 服务中，
http.ServeMux默认不 recover，每个 handler 都应自行兜底，或统一用中间件包装
recover 后别继续用可能已损坏的数据
recover() 的作用只是让 goroutine “软着陆”，不是时光倒流。如果 panic 发生在修改结构体字段中途、或刚 close 了一个 channel 又往里 send，recover 成功后那些副作用都还在——你拿到的可能是半初始化的 struct、已关闭的 channel、或者泄露的文件句柄。
立即学习“go语言免费学习笔记（深入）”；
- ✅ 安全做法：recover 后只做三件事——记录日志（带 stack trace）、清理本地资源（如临时文件、未完成的 buffer）、返回错误响应或退出当前任务
- ❌ 危险操作：recover 后继续调用
user.Save()或db.Exec(...)，尤其当 panic 就发生在这些调用内部时 - ⚠️ 特别注意：
panic(nil)是个例外，它无法被recover()捕获，会直接终止程序
真正难的从来不是怎么写 recover，而是判断该不该 panic、在哪一层 recover、recover 之后敢不敢继续跑业务逻辑。状态不一致比崩溃更危险，而日志里那一行没打全的 stack trace，往往就是线上问题定位的唯一线索。
