recover必须在同goroutine的defer匿名函数中调用才能捕获panic，跨goroutine无效，且需类型断言安全使用返回值，不可滥用替代error处理。
recover 必须在 defer 中调用，且只能捕获同 goroutine 的 panic
这是最常踩的坑：把 recover() 放在普通函数里、或放在主 goroutine 的 defer 里却想捕获子 goroutine 的 panic，结果程序照样崩溃。Go 的 panic/recover 是协程局部的，recover() 只对当前 goroutine 生效，跨 goroutine 完全无效。
- ❌ 错误写法：
go func() { panic("boom") }()后在 main 里defer recover()—— 捕不到，主程序退出 - ✅ 正确写法：panic 和
recover()必须在同一个 goroutine 内，且recover()必须包裹在defer的匿名函数中（不能直接写defer recover()） - ⚠️ 注意：
defer func() { recover() }()是合法的；但defer recover()是非法的——它会在 defer 注册时就执行，而非 panic 发生后
panic 参数是 interface{}，但 recover 返回值需类型断言才能安全使用
panic() 可以传任意类型：字符串、error、整数、结构体，但 recover() 返回的是 interface{}，不加判断直接打印或转换可能 panic（比如断言为 *os.PathError 却实际是字符串）。
- 推荐统一用
fmt.Sprint(err)输出错误信息，避免类型断言失败 - 若需区分错误类型，务必先用
if err != nil判断，再用switch err.(type)分支处理 - 常见误操作：直接写
err.(error).Error()—— 当 panic 传的是"string"时会再次 panic
defer 执行顺序决定 recover 是否“来得及”
panic 触发后，会立刻停止当前函数后续代码，但会按栈逆序执行所有已注册的 defer。所以 recover() 必须在 panic 发生前就注册好，否则根本没机会运行。
- ✅ 正确顺序：
defer func() { recover() }()→panic("x")→ defer 执行 → recover 捕获 - ❌ 错误顺序：
panic("x")→defer func() { recover() }()—— defer 还没注册，panic 已经杀掉函数了 - 多个 defer？记住：后注册的先执行。如果写了两个 defer，recover 必须在更靠近 panic 的那个 defer 里，否则可能被前面的 defer 提前“吃掉”返回值
不要用 panic/recover 替代 error 返回，它们解决的是不同问题
panic 不是“高级错误”，而是表示“程序状态已损坏，无法继续安全执行”。比如空指针解引用、map 写入 nil、并发写 map——这些本该在开发/测试阶段暴露，而不是靠 recover 挽救。
立即学习“go语言免费学习笔记（深入）”；
- ✅ 合理场景：初始化失败（端口被占、配置文件损坏）、不可恢复的系统级错误
- ❌ 滥用场景：HTTP 请求超时、数据库查无结果、用户输入格式错误——这些都应该用
error返回，由调用方决定重试/提示/降级 - 性能影响：panic/recover 触发时会构建完整堆栈，开销远高于 error 判断；频繁 panic 会让 pprof 看起来像在跑“堆栈生成器”
真正难的不是写对 recover，而是判断“这个 panic 到底该不该 recover”。很多线上 panic 其实是内存越界或竞态导致的未定义行为，强行 recover 只会让问题延迟爆发，更难定位。
