recover必须在defer函数中调用才能捕获panic，用于恢复goroutine控制流并执行清理逻辑，但无法跨goroutine生效，也不适用于预期错误处理。
在Go语言中，recover是处理程序运行时panic异常、避免进程直接崩溃的关键机制。它不能像普通函数一样随意调用，必须结合defer才能生效，其核心作用是在发生panic时恢复程序的正常控制流，让代码有机会执行清理逻辑或安全退出。
recover的基本使用模式
最标准的recover用法是在一个defer声明的匿名函数中调用它。当函数内部或其调用链中出现panic时，defer函数会被触发，此时recover可以捕获这个panic，并返回传递给panic的值（通常是错误信息）。如果没有发生panic，recover会返回nil。
典型代码结构如下：
func safeFunction() {defer func() {
if r := recover(); r != nil {
fmt.Println("捕获到异常:", r)
}
}()
// 可能引发panic的代码，例如：
panic("something went wrong")
}
在这个例子中，即使执行了panic，程序也不会立即退出，而是会打印出“捕获到异常”的信息，然后从safeFunction中返回，继续执行后续代码。
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
recover的应用场景与注意事项
recover主要用于需要保证程序健壮性的场合，比如服务器的请求处理器。你可以在每个处理入口处使用defer+recover，防止某个请求因未预料的错误（如数组越界、空指针解引用）导致整个服务宕机。
- 必须在defer中调用：recover只有在被defer修饰的函数内部调用才有效。如果在函数的主逻辑里直接写recover()，它无法捕获当前的panic。
- 只能恢复本Goroutine的panic：recover无法捕获其他协程中发生的panic。每个Goroutine的panic和recover是相互独立的。如果子协程发生了panic，且没有在子协程内部用recover处理，那么该子协程会崩溃，但不会影响父协程（除非父协程在等待它）。
- 用于资源清理和优雅降级：结合defer，可以在recover后执行文件关闭、连接释放等操作。即使发生了严重错误，也能确保关键资源不被泄露，实现安全退出。
常见误区与失效情况
理解recover何时会失效，能帮助写出更可靠的代码。
- recover写在panic之前：如果在代码顺序上，recover的调用出现在panic之前，那么当panic发生时，那个recover早已执行过了，自然无法捕获。必须确保defer/recover的声明在panic代码的“上方”（即在语法上先定义）。
- 跨Goroutine无效：在一个Goroutine里尝试用recover捕获另一个Goroutine的panic是徒劳的。例如，在main函数里defer recover，然后启动一个会panic的goroutine，main里的recover对此无能为力。
- 不是所有错误都适合用panic/recover：对于预期内的错误，如参数校验失败、文件不存在等，应该使用error类型显式返回。panic/recover更像是应对“不应该发生”的严重程序错误的最后防线。
基本上就这些。掌握好defer、panic和recover三者的配合，就能在Go程序中构建出既能抵御意外冲击，又能安全清理退出的稳定模块。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
