Go语言通过defer、panic和recover实现错误恢复机制：panic触发运行时恐慌，中断当前流程；defer延迟执行函数，确保recover有机会捕获panic；recover仅在defer中有效，用于捕获panic值并恢复执行，防止程序崩溃。该机制常用于Web服务或goroutine中保护关键逻辑，避免单个错误导致整个服务失效。注意recover无法跨goroutine捕获，且应避免滥用panic，常规错误应通过error返回。
Go语言中通过 defer、panic 和 recover 三个关键字协同工作，实现错误恢复机制，防止程序因异常情况导致整个服务崩溃。这种机制虽然不是传统意义上的异常处理，但在关键服务中可以有效控制流程，避免程序退出。
1. panic：触发运行时恐慌
当程序遇到无法继续执行的错误时，可以主动调用 panic 中断当前流程。例如访问越界、空指针、不满足前提条件等场景。
if criticalCondition {
panic("critical error: service cannot continue")
}
执行 panic 后，当前函数停止运行，已注册的 defer 函数仍会执行，然后逐层向上回溯，直到协程结束，除非被 recover 捕获。
2. defer：延迟执行的关键
defer 用于延迟执行函数调用，通常用于资源释放、日志记录或错误恢复。在 panic 触发后，defer 仍然会执行，这为 recover 提供了执行时机。
立即学习“go语言免费学习笔记（深入）”；
典型用法是在函数开头使用 defer 包裹 recover 逻辑：
func safeOperation() {
defer func() {
if r := recover(); r != nil {
log.Printf("recovered from panic: %v", r)
}
}()
// 可能触发 panic 的操作
mightPanic()
}
3. recover：捕获 panic 实现恢复
recover 只能在 defer 函数中有效调用，用于捕获 panic 的值并恢复正常执行流程。如果当前 goroutine 没有 panic，recover 返回 nil。
使用 recover 时需注意：
- recover 必须直接在 defer 的匿名函数中调用，否则无效
- recover 后程序不会回到 panic 点，而是从 defer 函数继续执行
- recover 捕获后建议记录日志或发送监控告警
4. 实际服务中的保护模式
在 Web 服务或 RPC 处理器中，常见做法是对每个请求处理函数进行 recover 保护，防止单个请求崩溃影响整个服务。
func handler(w http.ResponseWriter, r *http.Request) {
defer func() {
if r := recover(); r != nil {
log.Printf("handler panic: %v\n", r)
http.Error(w, "internal error", 500)
}
}()
// 处理逻辑
processRequest(r)
}
对于 goroutine，需特别注意：主协程的 recover 无法捕获子协程的 panic。每个子协程应独立设置 defer-recover 机制。
基本上就这些。Go 不鼓励滥用 panic，正常错误应通过 error 返回。panic 仅用于真正异常的情况，recover 则作为最后一道防线，确保服务的稳定性。
