recover必须写在defer函数内才能捕获panic，因其仅在panic传播且goroutine执行defer时有效；panic非error，应限于不可恢复的逻辑错误；goroutine内panic无法被外层recover捕获，需各自防护；recover后不应继续关键业务逻辑。
recover 必须写在 defer 函数里，否则永远拿不到 panic
很多人以为只要 recover() 写在 panic() 后面就能捕获，结果发现返回总是 nil。根本原因：recover() 只在 panic 正在传播、且当前 goroutine 正在执行 defer 函数时才有效。
-
recover()单独写在普通函数体里（比如紧跟panic("x")下一行）——压根不会执行，因为 panic 已经终止了函数 - 把
recover()提到外层函数去调用（比如封装成safeRecover()），再从 defer 里调用它——无效，因为此时调用栈已离开 panic 上下文 - 正确姿势只有一种：
defer func() { if r := recover(); r != nil { /* 处理 */ } }()
示例对比：
func bad() {
panic("boom")
recover() // ❌ 永远不执行
}
<p>func good() {
defer func() {
if r := recover(); r != nil {
log.Printf("caught: %v", r)
}
}()
panic("boom") // ✅ defer 在 panic 后立即触发，recover 能捕获
}panic 不是 error，别拿它处理业务错误
Go 的哲学很明确：可预期的失败走 error 返回，不可恢复的崩溃才用 panic。混用会导致测试难写、监控失真、日志混乱。
- 文件不存在、网络超时、JSON 解析失败 —— 这些都该返回
error，不是panic -
panic应该留给真正“程序逻辑已错乱”的场景：比如初始化配置缺失导致后续所有功能失效、断言失败（assert(len(s) > 0)但s是空切片）、空指针解引用（虽通常由 runtime 自发触发） - 标准库中
json.Unmarshal遇到非法结构体字段会panic，是因为它认为这是开发者严重误用，而非运行时偶然错误
传参建议：panic(errors.New("xxx")) 或带上下文的 panic(fmt.Errorf("failed to open %s: %w", path, err))，避免裸字符串。
立即学习“go语言免费学习笔记（深入）”；
goroutine 里的 panic 无法被外层 recover 捕获
这是线上最常翻车的点：HTTP handler 里起一个 go func() { doWork() }()，里面 panic 了，主流程完全无感，日志里也找不到痕迹，只看到连接莫名断开。
-
panic/recover是 goroutine 局部机制，主 goroutine 的defer+recover对子 goroutine 的 panic 完全无效 - 解决方案不是“加个全局 recover”，而是在每个可能出问题的 goroutine 内部做防护
- 推荐封装 worker 模式，或用
errgroup.Group统一管理
正确做法示例：
go func() {
defer func() {
if r := recover(); r != nil {
log.Printf("worker panic: %v", r)
}
}()
doWork()
}()recover 后别继续跑关键业务逻辑
recover 能让程序不死，但不能修复已被破坏的状态。panic 往往意味着变量、锁、channel、文件句柄等已处于不确定状态。
- 不要在 recover 后继续更新数据库、提交事务、修改共享 map —— 极大概率引发数据不一致
- 安全做法是：记录 panic 栈 + 清理局部资源（如关闭临时文件、释放内存缓冲区）→ 返回错误或退出当前任务
- HTTP 中 recover 后应返回 500 响应，并带上 trace ID 方便排查，而不是静默吞掉或重试
最容易被忽略的是：recover 后的函数并不会从 panic 那行继续执行，而是从 defer 函数返回后，接着运行 panic 所在函数的「上一层」逻辑——这和 try/catch 的“继续执行 catch 后代码”完全不同。
