17370845950

recover()只能在同Goroutine的defer中捕获本Goroutine的panic，因各Goroutine调用栈独立；需在出问题的Goroutine内用defer recover()，或用errgroup.Group、带缓冲channel统一处理错误。

为什么直接用 recover() 在 Goroutine 里捕获不到 panic

因为每个 Goroutine 有独立的调用栈，recover() 只能在当前 Goroutine 的 defer 中、且在同层 panic() 后立即生效。如果在子 Goroutine 里 panic，主 Goroutine 的 recover() 完全无感知——这不是 bug，是设计使然。

常见错误现象：go func() { panic("oops") }() 导致进程崩溃，但主流程没报错、也没日志；或者用了 defer recover() 却始终返回 nil。

• 必须在出问题的 Goroutine 内部做 defer recover()
• 不能指望外层函数“代为恢复”
• 如果 Goroutine 是通过第三方库启动（如 http.HandlerFunc），需确认它是否已封装错误处理

用 errgroup.Group 统一收集 Goroutine 错误

当多个 Goroutine 并发执行且需要任一失败就中止、或等全部完成再汇总错误时，errgroup.Group 是最轻量可靠的方案。它底层用 sync.WaitGroup + sync.Once 控制错误传播，天然支持上下文取消。

使用场景：批量请求 API、并行初始化资源、多路数据写入。

• 调用 eg.Go(func() error { ... }) 启动任务，返回的 error 会被自动收集
• 首次非 nil 错误会触发所有未开始任务的取消（如果传了 ctx）
• eg.Wait() 返回第一个非 nil 错误；若要获取全部错误，得自己加切片缓存

eg, ctx := errgroup.WithContext(context.Background())
for i := range urls {
    url := urls[i]
    eg.Go(func() error {
        resp, err := http.Get(url)
        if err != nil {
            return fmt.Errorf("fetch %s: %w", url, err)
        }
        defer resp.Body.Close()
        return nil
    })
}
if err := eg.Wait(); err != nil {
    log.Printf("at least one failed: %v", err)
}

通过 channel 传递错误（适合简单控制流）

当 Goroutine 数量固定、逻辑简单，且不需要取消语义时，用带缓冲的 chan error 是最直观的方式。关键点在于 channel 容量必须 ≥ Goroutine 数量，否则可能阻塞。

容易踩的坑：chan error 不带缓冲 + 多个 Goroutine 同时 send → 死锁；忘记关闭 channel → range 永不退出。

• 声明时用 make(chan error, len(tas

  

  ks))
• 每个 Goroutine 执行完必须 errCh ，即使 err == nil（否则主 Goroutine 等不到）
• 主流程用 for i := 0; i 更安全，比 range 明确

HTTP handler 等框架内 Goroutine 的错误陷阱

像 http.ServeMux 或 Gin 的 handler 函数，本身就在独立 Goroutine 中运行，但框架通常不 recover。一旦 handler panic，连接会断开，日志可能只显示 “http: panic serving”，看不到堆栈。

解决思路不是全局捕获，而是中间件式兜底：

• 自定义 wrapper：在 handler 外包一层 func(w http.ResponseWriter, r *http.Request) { defer func() { if r := recover(); r != nil { log.Printf("panic: %v", r) } }(); handler(w, r) }
• Gin 用户可注册 gin.RecoveryWithWriter()，但注意它只捕获 handler 顶层 panic，不处理子 Goroutine
• 任何在 handler 内启的 Goroutine，仍需各自做 defer recover()

真正麻烦的是那些被遗忘的匿名 Goroutine：比如 go log.Println("debug") 里写了 panic()，没人管，也不报错，直到某天 OOM 或 goroutine 泄漏暴露出来。