Go中recover使用详解与技巧

大家好，我们又见面了啊~本文《Go中recover使用方法详解》的内容中将会涉及到等等。如果你正在学习Golang相关知识，欢迎关注我，以后会给大家带来更多Golang相关文章，希望我们能一起进步！下面就开始本文的正式内容~

recover必须在defer函数内调用才有效，否则返回nil；它仅在goroutine处于panic状态且位于defer函数体内时捕获panic，捕获后原函数不继续执行，仅恢复上层控制流。

recover 必须在 defer 函数里调用，否则返回 nil

这是最常踩的坑：把 recover() 写在普通函数体里，甚至包级变量初始化中，它永远不生效。Go 规定 recover() 只有在当前 goroutine 正处于 panic 状态、且调用点位于被 defer 延迟执行的函数内部时，才可能捕获 panic。

• ✅ 正确写法：

  defer func() {
      if r := recover(); r != nil {
          fmt.Println("捕获到 panic:", r)
      }
  }()

• ❌ 错误写法：

  if r := recover(); r != nil { /* 永远进不来 */ }

  或

  func bad() {
      recover() // 这里调用毫无意义
  }

• ⚠️ 注意：即使 defer 存在，如果 recover() 不是直接在 defer 的匿名函数体内调用（比如传给另一个函数再调），也会失效

recover 捕获后，原函数不会继续执行，但调用栈停止展开

很多人误以为 recover() 能“回滚”到 panic 发生前那一行继续跑。实际上，一旦 panic() 触发，当前函数立即终止，所有后续语句（包括 panic 行之后的代码）都不执行；recover() 只是让程序从 panic 的“崩溃路径”跳出来，回到 defer 所在函数的下一行——而那个函数本身已经 return 了。

• 例如：g() 中 panic("x") → g() 立刻退出 → f() 的 defer 开始执行 → recover() 成功 → f() 继续执行 fmt.Println("Returned normally from g.") 之后的代码？不，这行根本不会打印，因为 g() 已经没返回
• 真正恢复的是“上层控制流”，不是“原函数执行流”
• 所以别指望在 recover 后重试出问题的操作；它只适合做清理、记录、降级响应等收尾动作

Web 服务中用 recover 隔离单请求 panic，避免整个 server 崩溃

这是 recover() 最典型也最有价值的使用场景。HTTP handler 是天然的 panic 边界：一个请求 panic 不该 kill 掉整个 http.Server。

• 必须对每个 handler（或中间件）单独加 defer + recover，全局注册无效
• 推荐封装成中间件：

  func recoverMiddleware(next http.Handler) http.Handler {
      return http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
          defer func() {
              if err := recover(); err != nil {
                  http.Error(w, "Internal Error", http.StatusInternalServerError)
                  log.Printf("Panic in %s %s: %v", r.Method, r.URL.Path, err)
              }
          }()
          next.ServeHTTP(w, r)
      })
  }

• 注意：recover 不会捕获由其他 goroutine 引发的 panic（比如异步启动的 goroutine），那些需要单独处理

recover 返回值类型是 any，类型断言要小心

Go 1.18+ 中 recover() 返回 any（即 interface{}），你不能直接当字符串或错误用，得判断类型再处理。

• 常见 panic 参数类型：字符串（panic("msg")）、error 实例、自定义结构体（如 panic(&MyErr{})）
• 安全做法是用 switch r := recover().(type) 分支处理：

  switch r := recover().(type) {
  case string:
      log.Printf("panic string: %s", r)
  case error:
      log.Printf("panic error: %v", r)
  default:
      log.Printf("panic unknown type %T: %v", r, r)
  }

• 别直接写 fmt.Sprintf("%v", recover()) —— 如果 panic 是 nil，recover() 返回 nil，sprintf 会 panic（nil pointer dereference）

recover 不是 try-catch，它不提供上下文回溯、无法重入原逻辑、也不能跨 goroutine 传播。它的存在意义很朴素：让程序在明确知道“这里可能崩”的地方，有机会做最后的体面收场。用错位置、期望过高、忽略类型安全，是三个最容易让 recover 形同虚设的原因。

今天带大家了解了的相关知识，希望对你有所帮助；关于Golang的技术知识我们会一点点深入介绍，欢迎大家关注golang学习网公众号，一起学习编程~