Golang recover在错误处理中的合理用法

recover必须在defer中调用才有效，仅当goroutine处于panic状态时在defer函数内调用才可捕获panic，直接调用或跨goroutine均无效，且recover后需手动处理流程而非自动续执行。

recover 必须在 defer 中调用才有效

recover 不是普通函数，它只在 defer 函数执行期间、且当前 goroutine 正处于 panic 状态时才有意义。直接在普通函数体里调用 recover() 永远返回 nil，不会捕获任何 panic。

常见错误写法：

func badExample() {
    recover() // 这里永远无效
    panic("boom")
}

正确姿势是：必须搭配 defer，且 defer 的函数要能访问到 panic 值：

• 把 recover() 放在 defer 的匿名函数或命名函数内部
• 确保 defer 注册在 panic 发生前（即 panic 调用之前）
• 不能跨 goroutine 使用：goroutine A panic，goroutine B 的 defer + recover 无法捕获

recover 只能捕获本 goroutine 的 panic

Go 的 panic 是 goroutine 局部的，recover 对其他 goroutine 的崩溃完全无感。这导致很多误以为“全局兜底”的尝试失败，比如在 main 函数里 defer recover 却想捕获子 goroutine 的 panic。

典型陷阱场景：

• 启动一个 goroutine 执行可能 panic 的逻辑，main 里 defer recover —— 无效
• 使用 http.DefaultServeMux 或框架（如 Gin/echo）时，handler panic 后 HTTP 连接直接断开，除非框架内部做了 recover（如 Gin 默认 recover 中间件）
• 想靠一次 recover 拦住所有错误？不行。每个可能 panic 的 goroutine 都得自己配 defer+recover

若需统一处理子 goroutine panic，得手动封装：

func safeGo(f func()) {
    go func() {
        defer func() {
            if r := recover(); r != nil {
                log.Printf("goroutine panicked: %v", r)
            }
        }()
        f()
    }()
}

recover 后程序不会自动“恢复执行”，需显式控制流程

recover 的作用只是让 goroutine 从 panic 状态中退出，**不等于继续执行 panic 后面的代码**。一旦 panic 发生，控制权就跳转到 defer 链，原函数后续语句不再执行。

所以别指望这样写：

func wrongResume() {
    defer func() {
        recover()
    }()
    panic("fail")
    fmt.Println("this never runs") // 永远不会打印
}

合理做法是：在 defer 中拿到 panic 值后，做清理、记录、返回错误或重试逻辑，但主流程必须由你主动安排：

• 不要依赖“recover 后自动续跑”，而是把关键路径拆成可中断+可重入的单元
• 如果函数有副作用（如写文件、发请求），recover 后需判断是否已部分完成，避免重复或遗漏
• HTTP handler 中 recover 后应显式写 response，否则客户端会卡死或收到空响应

不该用 recover 替代错误返回，更不该用于控制流

Go 的哲学是“error is value”。99% 的业务错误（I/O 失败、参数非法、网络超时）应该走 error 返回值，而不是故意 panic 再 recover。滥用 recover 会让调用方无法预判行为，也破坏静态分析和工具链支持。

适合 panic 的场景极少，仅限于：

• 程序无法继续运行的致命状态（如配置严重缺失、初始化失败）
• 断言失败（x.(T) 类型断言失败，且你 100% 确认不该发生）
• 内部 invariant 被破坏（如 switch 漏掉 case，且该类型本不该出现）

反过来，这些属于反模式：

• 用 panic 表示“用户输入格式错误”——该返回 fmt.Errorf
• 用 recover 模拟 try/catch 做常规分支（如“找不到就新建”）——该用 if err != nil
• 在库函数中随意 panic，强迫调用方加 defer recover —— 库应暴露 error

真正难的不是怎么写 recover，而是判断：这个 panic，到底该不该发生？