如何使用Golang recover捕获panic_Golang异常恢复机制解析

recover必须在defer中调用才有效，仅在panic发生且当前goroutine的defer链执行时返回panic值，否则返回nil；它不回滚副作用，仅实现goroutine软着陆。

recover 必须在 defer 中调用才有效

直接在普通函数体里写 recover() 永远返回 nil，它只在 panic 正在发生、且当前 goroutine 的 defer 链正在执行时才有意义。Go 运行时会把 panic 的值“传递”给正在执行的 defer 函数中的 recover() 调用。

• 必须搭配 defer 使用，典型模式是：

  defer func() {
      if r := recover(); r != nil {
          // 处理 panic 值
          log.Printf("panic recovered: %v", r)
      }
  }()

• 如果 defer 是匿名函数，且该函数内没调用 recover()，或者调用位置不在 panic 触发之后（比如提前 return），就捕获不到
• recover 不是“全局开关”，它只对**当前 goroutine** 有效；其他 goroutine 的 panic 不会影响它，也不能被它捕获

recover 返回值类型是 interface{}，需手动断言

recover() 返回的是任意类型的 panic 值，不是错误对象。如果你用 panic("oops")，recover 得到的是 string；如果用 panic(errors.New("db fail"))，得到的是 *errors.errorString；甚至可能是自定义结构体。

• 不要假设返回值一定是 error 类型，直接转成 error 可能 panic：

  if err := recover().(error); err != nil { ... } // 危险！类型断言失败会再 panic

• 安全做法是先做类型检查：

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

• 注意：nil 本身不能被 recover 捕获 —— panic(nil) 会导致程序直接崩溃，recover() 无法拦截

recover 无法恢复已释放的资源或已提交的状态

recover 只是让 goroutine 从 panic 状态中“软着陆”，继续执行 defer 后的代码，但它不撤销任何已发生的副作用。

• 文件已写入、数据库事务已提交、HTTP 响应头已发送……这些都不会回滚
• recover 后继续执行的逻辑，仍要面对一个可能处于不一致状态的对象（比如 struct 字段部分初始化失败）
• 常见误用：在 HTTP handler 里 recover 后直接返回 200 OK，但其实业务逻辑已经中断，响应内容为空或错乱
• 正确思路是：recover → 记录上下文（如 request ID、panic 栈）→ 返回 500 或降级响应 → 避免暴露内部细节

嵌套 defer 和多层 recover 的行为容易误判

一个函数里可以有多个 defer，它们按后进先出（LIFO）顺序执行；每个 defer 里的 recover() 都有机会捕获 panic，但只有第一个成功调用的能拿到 panic 值，后续都返回 nil。

• 下面这段代码只会打印一次 "recovered"：

  func f() {
      defer func() {
          if r := recover(); r != nil {
              log.Println("recovered")
          }
      }()
      defer func() {
          if r := recover(); r != nil {
              log.Println("also recovered?") // 永远不会执行
          }
      }()
      panic("boom")
  }

• 跨函数调用时，recover 只作用于当前函数的 defer 链；父函数即使有 defer + recover，也捕获不到子函数里已被子函数自身 recover 掉的 panic
• 在中间件或 wrapper 函数中统一 recover 是可行的，但要注意别和业务层的 recover 冲突 —— 建议只在最外层（如 HTTP handler、goroutine 入口）做一次 recover

recover 不是 try/catch，它没有“异常传播”概念，也没有 finally 语义。真正难的从来不是写那行 recover()，而是判断哪里该用、哪里不该用，以及 panic 之后你还敢信任哪些数据。