17370845950

recover只能在defer函数中生效，且仅能捕获runtime.panic()引发的panic；对runtime.throw()或fatal错误无效，且无法跨goroutine捕获。

recover 只能在 defer 函数里生效

recover() 不是普通函数，它只在 defer 声明的匿名函数或命名函数内部调用时才有效。直接在函数体里写 recover() 会永远返回 nil，捕获不到任何 panic。

• 错误写法：recover() 写在 if 分支、循环体或函数开头 —— 完全无效
• 正确写法：必须包裹在 defer func() { ... }() 里，且该 defer 要在可能触发 panic 的语句之前注册
• 常见疏漏：把 defer 放在 panic 之后，比如先除零再 defer —— 此时 panic 已发生，defer 还没注册，自然无法捕获

recover 能捕获哪些 panic，不能捕获哪些

recover() 只能捕获由 runtime.panic()（包括用户显式调用 panic()）引发的运行时异常；对 runtime.throw() 和 runtime.fatal() 触发的崩溃（如栈溢出、内存耗尽、非法指针解引用等底层致命错误），recover() 完全无能为力，程序会直接终止。

• 能捕获：数组越界、空接口方法调用、手动 panic("xxx")、panic(errors.New(...))
• 不能捕获：panic: runtime error: invalid memory address or nil pointer dereference（某些情况下可捕获，但非所有 nil 解引用都走 panic 路径）、fatal error: stack overflow、throw: out of memory
• 关键判断依据：看 panic 错误信息是否以 panic: 开头并伴随完整 goroutine stack trace —— 这类通常可 recover；若直接输出 fatal error: 或程序静默退出，则不可恢复

recover 后如何安全继续执行

成功调用 recover() 后，当前 goroutine 恢复执行，但要注意：panic 已“消耗”，不能再被二次捕获；原 panic 点之后的代码不会自动重试，需手动处理逻辑分支。

• 必须检查返回值：err := recover()，若为 nil，说明没发生 panic，别误当错误处理
• 不要在 recover 后“假装无事发生”继续用已损坏状态（例如切片越界后仍访问 s[2]）
• 典型做法：记录日志 + 返回默认值/错误值 + 清理资源（文件句柄、锁、channel 关闭等）
• 避免在 recover 后再调用 panic —— 除非你明确想把错误向上传递，否则容易掩盖原始上下文

func safeDiv(a, b int) (int, error) {
    defer func() {
        if r := recover(); r != nil {
            fmt.Printf("recover from panic: %v\n", r)
        }
    }()
    if b == 0 {
        panic("division by zero")
    }
    return a / b, nil
}

跨 goroutine 的 panic 无法被 recover

每个 goroutine 有独立的调用栈，recover() 只能捕获**当前 goroutine** 中由 panic() 触发的异常。主 goroutine 中的 defer+recover 对子 goroutine 的 panic 完全无效。

• 子 goroutine panic 未被处理 → 该 goroutine 终止，但主 goroutine 继续运行（除非设置了 GODEBUG=catchpanics=1，不推荐）
• 若需统一兜底，应在每个可能 panic 的 goroutine 内部单独加 defer+recover
• 注意：goroutine 泄漏风险 —— recover 后未关闭 channel、未释放锁、未关闭文件等，比 panic 本身更难排查

真正容易被忽略的是 panic 的传播边界：它不会跨 goroutine，也不跨 CGO 调用，更不会穿透到系统线程。recover 不是万能兜底，而是一个精确作用于当前函数调用栈末尾的“刹车片”——踩得准才有用，踩歪了反而更危险。