如何在Golang中捕获并记录协程异常_Golang goroutine panic处理技巧

goroutine 中的 panic 必须在内部用 recover 捕获，因为 panic 不跨协程传播，子协程 panic 后静默退出，主协程不受影响但可能导致数据丢失、资源泄漏、任务中断且无日志；recover 仅在本协程 defer 中有效，需配合 debug.Stack() 结构化记录并及时退出，不可继续执行业务逻辑。

goroutine 中的 panic 为什么必须在内部用 recover 捕获

因为 Go 的 panic 不会跨 goroutine 传播——子协程 panic 后，主协程照常运行，但该子协程会静默退出。表面看程序“没崩”，实则可能已丢失数据、泄漏文件句柄、中断定时任务，且无日志可查。更危险的是：某些 runtime 场景下（如未捕获的 panic 发生在非 main 协程但主线程很快退出），整个进程仍会终止。

• recover 只在当前 goroutine 的 defer 函数中调用才有效；写在普通逻辑里或别的 goroutine 里，返回 nil
• panic 展开栈时，只会执行本 goroutine 已注册的 defer，不会触发其他协程的 defer
• 不处理 ≠ 安全，而是把问题藏进黑盒：你看到 ps 还活着，但 worker 数悄悄少了 3 个

怎么写一个真正可用的 defer + recover 模板

不能只打印一句“捕获到 panic”，否则堆栈丢失、上下文不清、无法定位是哪个请求/任务出的问题。标准做法是立刻获取完整堆栈并结构化记录。

go func() {
    defer func() {
        if r := recover(); r != nil {
            // 获取 panic 值和堆栈
            stack := debug.Stack()
            log.Printf("panic recovered in worker: %v\n%s", r, stack)
            // 上报监控、触发告警等可在此扩展
        }
    }()
    doSomethingRisky()
}()

• 必须用 debug.Stack()（不是 debug.PrintStack()），前者返回 []byte 可写入日志字段，后者直接输出到 stderr，难以统一收集
• 不要在 recover 后继续执行业务逻辑——状态很可能已不一致；应记录后退出，或按需重启该 worker
• 避免在 defer 里调用可能 panic 的操作（比如向已关闭 channel 发送、对 nil map 写入），否则原 panic 被覆盖，彻底丢失线索

如何避免重复写 defer + recover ——封装 goSafe 函数

每个 go 都手动包一层 defer 易漏、难维护。推荐封装一个通用启动函数，自动注入 recover 逻辑，并支持传入 context.Context 和日志实例。

func goSafe(ctx context.Context, logger *log.Logger, f func()) {
    go func() {
        defer func() {
            if r := recover(); r != nil {
                stack := debug.Stack()
                logger.Printf("panic in safe goroutine: %v\n%s", r, stack)
                // 可选：上报 metric、触发告警、发送到 error channel
            }
        }()
   
     f()
    }()
}

• 调用时只需 goSafe(ctx, logger, func() { handleMsg(msg) })，简洁且无遗漏风险
• 若需集中响应错误（如任意 worker panic 就取消全部任务），可在 recover 后调用 cancel()（配合 context.WithCancel）
• 别把 error channel 设成无缓冲：errCh := make(chan error) 会导致所有出错 goroutine 在 send 时永久阻塞

哪些场景必须加 recover，哪些不该用

recover 不是兜底银弹，它解决的是“运行时崩溃防护”，不是“业务错误处理”。滥用会掩盖真实 bug，让本该失败的流程静默继续。

• 必须加：http.HandlerFunc 内部、长期运行的 for range time.Tick 循环、第三方 SDK 回调、反射调用、插件加载等不确定代码块
• 不该加：明确可预判的错误（如 json.Unmarshal 失败、数据库 Rows.Scan 错误）——这些该用 error 返回并由上层决策
• 特别注意：init 函数、包级变量初始化中发生的 panic 无法被任何 recover 捕获，会直接终止进程

真正难的不是写对 recover，而是在 panic 发生后判断：这个协程还能安全继续吗？资源是否已泄漏？状态是否已损坏？这时候堆栈只是起点，上下文（trace ID、输入参数、时间戳）和后续动作（降级、重试、告警）才是关键。