recover必须在defer中调用才有效，仅能捕获当前goroutine的panic，恢复后函数不会回到panic点，而是执行defer后的逻辑，常用于资源清理或防止程序崩溃，但应谨慎使用以避免掩盖严重错误。
在 Go 语言中，recover 是用于从 panic 中恢复程序正常执行的内建函数，通常与 defer 配合使用。虽然 recover 能避免程序因 panic 而崩溃，但使用时需注意多个关键点，否则可能达不到预期效果，甚至掩盖错误。
必须在 defer 函数中调用 recover
recover 只有在 defer 的函数中调用才有效。如果在普通函数或直接在代码流程中调用，recover 会返回 nil，无法捕获 panic。
错误示例：func bad() {
panic("oops")
recover() // 不会起作用
}
func good() {
defer func() {
if r := recover(); r != nil {
fmt.Println("recovered:", r)
}
}()
panic("oops")
}
recover 只能恢复当前 goroutine 的 panic
每个 goroutine 是独立的执行单元。在一个 goroutine 中使用 recover，无法捕获其他 goroutine 中发生的 panic。这意味着如果子 goroutine 发生 panic 且未在内部处理，主 goroutine 仍会继续运行，但子协程会终止。
建议：在启动的每个可能 panic 的 goroutine 中，都应单独设置 defer + recover。
立即学习“go语言免费学习笔记（深入）”；
例如：
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
go func() {
defer func() {
if r := recover(); r != nil {
log.Println("goroutine panic recovered:", r)
}
}()
// 可能 panic 的操作
}()
recover 后函数不会回到 panic 点，而是继续执行 defer 后的逻辑
recover 并不会“重试”或“跳过”panic 发生的位置。一旦 panic 被 recover，当前函数的后续代码不会继续执行，控制权会转移到 defer 函数，之后函数正常返回。
这意味着：recover 只能用于清理资源、记录日志或防止程序退出，不能用于修复错误状态后继续原流程。
谨慎使用 recover，避免掩盖真实问题
panic 通常是不可恢复的严重错误，比如数组越界、空指针解引用等。随意使用 recover 可能让程序在异常状态下继续运行，导致数据不一致或更严重的后果。
建议：
- 只在明确知道 panic 类型且能安全处理时使用 recover
- 框架或库中可适当使用 recover 防止用户代码导致整个服务崩溃（如 web 框架的中间件）
- 生产环境中 recover 后应记录详细上下文（如堆栈信息），便于排查
可通过 runtime/debug.Stack() 获取堆栈：
defer func() {
if r := recover(); r != nil {
fmt.Printf("panic recovered: %v\nstack:\n%s", r, debug.Stack())
}
}()
基本上就这些。recover 是一把双刃剑，合理使用能提升程序健壮性，滥用则会让错误变得难以追踪。理解其机制和限制是关键。
