recover必须在defer中调用，用于捕获同一goroutine内的panic，阻止程序崩溃并恢复执行，常用于Web中间件、解析器等场景以保证服务可用性，但不能跨goroutine生效，且不应滥用以避免状态不一致。
Go语言中的recover异常捕获机制，核心在于与defer和panic协同工作。它并非像其他语言的try-catch那样主动“监听”错误，而是一种在程序即将崩溃时进行“自救”的特殊手段。
recover的工作原理
recover是一个内建函数，它的唯一作用是让程序从panic（恐慌）状态中恢复。当一个函数内部或其调用链中发生panic时，正常的执行流程会被中断，函数开始逐层返回。在这个过程中，所有通过defer注册的延迟函数都会被依次执行。如果某个defer函数里调用了recover，并且此时程序正处于panic状态，那么recover就会生效，阻止程序继续崩溃，并将控制权交还给该函数，使其可以正常返回。
关键点在于：
- 必须与defer一起使用：recover只能在defer修饰的匿名函数内部调用才有效。在函数的普通逻辑流中调用recover，它会直接返回nil。
- 需要提前声明：defer语句必须在可能引发panic的代码之前定义。如果panic发生后再去定义defer，就来不及了。
- 恢复的是当前函数：recover成功后，触发panic的那个函数不会再继续执行（panic后面的代码不会运行），但它可以正常返回到调用者，从而避免整个程序退出。
recover的典型使用场景
recover主要用于处理那些不可预料的、严重的运行时错误，或者作为最后一道防线来保证服务的整体可用性。
立即学习“go语言免费学习笔记（深入）”；
-
防止除零等致命错误导致程序退出：比如在做数学计算时，可以预判可能出现的错误并用recover兜底。
func safeDivide(a, b int) (result int, err error) { defer func() { if r := recover(); r != nil { err = fmt.Errorf("发生了panic: %v", r) } }() result = a / b // 如果b为0，这里会panic return result, nil } - Web服务器的中间件/框架：这是recover最经典的应用。一个HTTP处理函数如果出现了未处理的panic，不应该导致整个服务器进程挂掉。框架通常会在分发请求前设置一个defer+recover，捕获任何处理函数抛出的panic，记录日志，然后返回一个500错误给客户端，保证其他请求不受影响。
- 解析器或复杂库的容错：在一个复杂的解析流程中，遇到无法解析的数据时，与其让整个程序崩溃，不如通过panic快速跳出深层嵌套的调用栈，然后在入口处用recover捕获，将其转换为一个普通的error返回给用户。
recover的限制和注意事项
尽管recover功能强大，但使用时必须非常谨慎，因为它可能会掩盖问题，导致程序处于不一致的状态。
- 无法跨goroutine工作：这是最重要的限制。在一个goroutine里发生的panic，只能由该goroutine内部的defer+recover来捕获。主goroutine里的recover无法捕获子goroutine的panic，反之亦然。每个并发任务需要自己管理自己的panic。
- 不应滥用：对于可以通过返回error来处理的普通错误，绝对不要使用panic和recover。它们是为真正的、意外的程序异常准备的，而不是常规的错误处理流程。
- 不能保证状态安全：当panic发生时，可能一些资源（如文件句柄、网络连接、锁）没有被正确释放。即使recover让它恢复了，这些泄漏的资源可能会导致后续问题。因此，recover后最好只做清理和记录日志，尽量不要再执行复杂的业务逻辑。
- 不建议恢复其他包的panic：你无法了解其他包内部的状态，贸然恢复其panic可能导致更隐蔽的bug。公有的API应该通过error来传达失败，而不是panic。
