如何用Go语言recover防止程序意外崩溃-Golang-PHP中文网

recover必须在defer中调用才有效，且仅对当前goroutine中正在传播的panic起作用；普通调用、跨goroutine、runtime致命错误均无法捕获。

如何用go语言recover防止程序意外崩溃

recover 必须在 defer 中调用才有效

Go 的 recover 不是全局异常捕获机制，它只在当前 goroutine 的 panic 正在被传播、且尚未退出函数时起作用。如果你写成普通调用（比如放在 if 分支里），recover 永远返回 nil，根本拦不住崩溃。

常见错误写法：

func badHandler() {
    if err := riskyOp(); err != nil {
        recover() // ❌ 完全无效，panic 还没发生
    }
}

正确姿势是搭配 defer，确保它在函数即将返回前执行：

func goodHandler() {
    defer func() {
        if r := recover(); r != nil {
            log.Printf("panic recovered: %v", r)
        }
    }()
    riskyOp() // 这里 panic，defer 中的 recover 才能捕获
}

recover() 必须出现在 defer 匿名函数内部，不能提前调用或放在其他 goroutine 里
如果函数内有多个 defer，recover 要放在最靠近 panic 发生点的那个 defer 中（通常就是最外层的）
recover 只对本 goroutine 有效，无法跨 goroutine 捕获 panic

recover 无法恢复已关闭的 channel 或已释放的资源

recover 只能停止 panic 的传播、让程序继续执行，但它不回滚状态。如果 panic 发生前已经关闭了 channel、写了文件、发了 HTTP 请求，这些操作不会自动撤销。

典型陷阱场景：

在 defer close(ch) 后又 panic → recover 成功，但 channel 已关，后续向它发送数据会直接 panic（且这次无法再 recover）
数据库事务未显式 rollback，仅靠 recover 会让数据处于不一致状态
HTTP handler 中 panic 后 recover 了，但 response writer 可能已被写入部分 header，客户端收到半截响应

所以必须配合显式清理逻辑：

func handleRequest(w http.ResponseWriter, r *http.Request) {
    ch := make(chan int, 1)
    defer close(ch) // 即使 panic 也会执行
<pre class="brush:php;toolbar:false;">defer func() {
    if r := recover(); r != nil {
        log.Println("recovered:", r)
        // 补充清理：比如 rollback tx、重置状态变量等
    }
}()

// ... 可能 panic 的业务逻辑

}