recover不是万能的错误处理工具，仅在defer中有效且只能捕获当前goroutine的panic；滥用会导致状态不一致、资源泄漏或掩盖问题。
recover 不是万能的错误处理工具，它只在 defer 中有效，且只能捕获当前 goroutine 的 panic；滥用或误用可能导致程序状态不一致、资源泄漏甚至掩盖真正问题。
recover 必须配合 defer 使用
recover 只有在 defer 函数中调用才可能生效。如果写在普通函数里，或者 panic 后未进入 defer 阶段（比如 panic 发生在 main 返回后），recover 就会返回 nil，起不到恢复作用。
- 正确写法：在 defer 匿名函数内调用 recover()
- 错误写法：在 panic() 后立刻调用 recover() —— 此时 panic 已中断执行流，不会执行到那行
- 常见陷阱：recover 放在 defer 外层函数体中（非匿名函数内部），实际没被调用
recover 无法跨 goroutine 捕获 panic
每个 goroutine 有独立的 panic/recover 机制。主 goroutine 中的 recover 对子 goroutine 的 panic 完全无效。
- 子 goroutine panic 会直接终止该 goroutine，除非它自己 defer+recover
- 若需统一处理，应在每个可能 panic 的 goroutine 内部做 recover（例如 worker 模式）
- 不要指望用一个全局 defer 来兜住所有协程的崩溃
recover 后状态可能已损坏，慎用“继续运行”
panic 往往意味着程序遇到了无法预期的异常（如空指针解引用、切片越界、channel 关闭后写入等）。recover 能让程序不退出，但不能自动修复被破坏的变量、锁状态、文件句柄或未完成的事务。
立即学习“go语言免费学习笔记（深入）”；
- 不要在 recover 后继续使用可能已被破坏的对象（比如 panic 前刚修改一半的结构体）
- 避免在 recover 后继续执行关键业务逻辑，尤其涉及数据一致性时（如数据库更新、支付流程）
- 更安全的做法是：recover → 记录日志 → 清理局部资源（如关闭临时文件）→ 返回错误或退出当前任务
不是所有 panic 都该被 recover
Go 鼓励用 error 显式表达可预期的失败，而 panic 应保留给真正的“程序无法继续”的严重异常（如断言失败、不可恢复的初始化错误）。
- 主动 panic（如 assert 或 validate 失败）通常不该被上层 recover，而是暴露给调用方快速失败
- 第三方库 panic 属于 bug，应提 issue 或降级版本，而非靠 recover 掩盖
- HTTP handler 中可适当 recover 防止整个服务崩溃，但要记录 panic 栈并返回 500，而不是静默吞掉
基本上就这些。recover 是一把双刃剑，用对了能提升健壮性，用错了反而让问题更难排查。关键不是“能不能恢复”，而是“该不该恢复”和“恢复之后怎么做”。
