如何使用Go语言recover对接异常告警逻辑-Golang-PHP中文网

recover必须在defer函数中直接调用才有效，仅能捕获同goroutine内未处理的panic；它不是error替代品，仅适用于不可恢复的严重错误，常规错误应返回error。

如何使用go语言recover对接异常告警逻辑

recover 必须在 defer 中调用才有效

Go 没有传统 try/catch，recover 不是“捕获异常”，而是从 panic 状态中恢复执行——但它只在 defer 函数里调用才起作用。如果写在普通函数体、或者 defer 外层，recover() 永远返回 nil，看起来“没生效”。

常见错误写法：

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

正确姿势是：

必须用 defer 包裹一个匿名或具名函数
该函数内第一件事就是调用 recover()，且不能有其他可能 panic 的操作前置
恢复后要显式处理错误值，否则 panic 会继续向上传播

recover 后怎么把 panic 信息发给告警系统

recover() 返回的是 interface{}，通常需要断言为 error 或直接格式化为字符串。但注意：不是所有 panic 都是 error 类型（比如 panic(42) 或 panic("string")），所以别硬转 error，用 fmt.Sprint() 更稳妥。

实操建议：

用 err := recover() 获取值，立即判空：if err == nil { return }
用 fmt.Sprint(err) 转成可读字符串，避免类型断言失败 panic
带上当前 goroutine 栈信息：debug.Stack()，方便定位问题源头
告警发送建议异步（如丢进 channel 或用 go func(){}()），避免阻塞恢复流程

示例关键片段：

GitHub Actions Retry Recovery Audit

审计 GitHub Actions 运行，检测失败后成功的重试恢复模式，量化 flaky 重运行的浪费。

下载

defer func() {
    if r := recover(); r != nil {
        msg := fmt.Sprint("PANIC: ", r)
        stack := string(debug.Stack())
        go alert.Send("go-panic", map[string]string{
            "message": msg,
            "stack":   stack,
        })
    }
}()

HTTP handler 中 recover 容易漏掉的边界情况

Web 服务里常在中间件或顶层 handler 套 recover，但有两个典型漏点：

goroutine 泄漏：如果 panic 发生在单独启动的 goroutine 里（比如 go http.Serve() 之外的手动 go doWork()），主 handler 的 defer 根本不覆盖它——每个 goroutine 需要自己配 defer+recover
http.Server 的 Shutdown() 或 Close() 期间 panic，不会被常规 handler 的 defer 捕获，得在 Server.RegisterOnShutdown() 或信号监听里补一层

更安全的做法是：对所有显式 go 启动的逻辑，都封装一层带 recover 的 wrapper：

func safeGo(f func()) {
    go func() {
        defer func() {
            if r := recover(); r != nil {
                alert.Send("goroutine-panic", map[string]string{"reason": fmt.Sprint(r)})
            }
        }()
        f()
    }()
}