panic 是 go 中触发异常的机制，recover 是用于捕获 panic 的唯一方式。具体使用场景包括中间件或框架中的错误兜底、处理不可预知的第三方库错误以及协程中防止 panic 影响主流程。recover 必须配合 defer 使用，且只能在引发 panic 的同一 goroutine 中生效，仅能捕获一次。此外，recover 不应替代正常错误处理，仅应在关键路径上谨慎使用，以避免掩盖问题本质。
在Go语言中，panic 和 recover 是处理程序运行时异常的重要机制。虽然不像其他语言那样有完整的异常体系，但Go通过简洁的设计让开发者可以在必要时优雅地恢复程序流程。
关键在于：不要滥用 panic，但在某些场景下，使用 recover 捕获 panic 可以防止整个程序崩溃。
什么是 panic 和 recover？
在Go中，panic 会中断当前函数的执行流程，并开始向上回溯调用栈，直到程序崩溃或被 recover 捕获。而 recover 只能在 defer 函数中生效，它用来捕获由 panic 引发的错误信息。
立即学习“go语言免费学习笔记（深入）”；
常见现象比如数组越界、空指针访问等，都会触发 panic。如果你希望在这种情况下不让整个程序挂掉，就可以考虑用 recover 来兜底。
举个例子：
func mayPanic() {
panic("something went wrong")
}
func safeCall() {
defer func() {
if r := recover(); r != nil {
fmt.Println("Recovered:", r)
}
}()
mayPanic()
}上面的例子中，safeCall 在调用 mayPanic 时会触发 panic，但由于有 defer + recover 的存在，程序不会直接崩溃，而是打印出 recover 的内容。
recover 的使用场景有哪些？
并不是所有错误都适合用 panic + recover 处理，但有些场景确实很合适：
中间件或框架中的错误兜底
比如一个HTTP中间件，在处理请求时某个环节出错，你不希望整个服务挂掉，可以在这个中间件里加上 recover。不可预知的第三方库错误
如果你调用了外部包，而它内部可能抛出 panic（比如解析配置出错），你可以在调用处加一层 recover 防止扩散。协程中处理错误
启动一个 goroutine 做一些任务，如果这个任务可能 panic，又不希望影响主流程，可以在 goroutine 内部做 recover。
当然，这些场景都要控制好使用范围，不能一上来就 defer recover，那样反而掩盖了真正的问题。
使用 recover 的几个注意事项
-
recover 必须配合 defer 使用
- 直接在函数入口处 defer 一个 recover 函数是最常见的做法。
-
只能在同一个 goroutine 中 recover
- 如果你在子 goroutine 中 panic，主 goroutine 是无法 recover 的，必须在子 goroutine 内部自己处理。
-
recover 只能捕获一次
- 一旦 recover 被调用，程序继续往下走，不会再重新进入 recover 流程。
-
不要用 recover 替代正常错误处理
- 正常的错误应该用 error 类型返回，只有在“真的无法继续”的时候才考虑 panic。
举个实际点的例子：
func handleRequest(w http.ResponseWriter, r *http.Request) {
defer func() {
if err := recover(); err != nil {
http.Error(w, "Internal Server Error", http.StatusInternalServerError)
log.Println("Recovered from panic:", err)
}
}()
// 一些可能 panic 的操作，比如类型断言或第三方库调用
doSomethingCritical()
}这样即使 doSomethingCritical() 抛出 panic，也不会导致整个服务崩溃，而是返回一个友好的错误页面。
小结一下
recover 并不是万能的，但它提供了一个“最后防线”来避免程序因为意外错误完全崩溃。在写库、中间件或者需要健壮性的服务时，合理使用 defer + recover 是一种成熟的做法。
基本上就这些。用的时候注意别过度依赖，也别完全不用，保持平衡才是关键。
