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、并行初始化资源、多路数据写入。
立即学习“go语言免费学习笔记（深入）”；
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 调用
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(tasks)) - 每个 Goroutine 执行完必须
errCh ，即使 <code>err == nil（否则主 Goroutine 等不到） - 主流程用
for i := 0; i 更安全，比 <code>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 泄漏暴露出来。
