errgroup.group 更可靠，因其内置“首次错误即终止”与“等待全部完成”的平衡逻辑，避免手动 channel 导致的竞态、死锁、资源泄漏及 panic 漏报；必须用 errgroup.withcontext 初始化并检查 ctx.err()。
errgroup.Group 为什么比自己用 channel 汇总错误更可靠
因为 errgroup.Group 内置了“首次错误即终止”和“等待全部完成”的平衡逻辑，而手动用 chan error 容易漏掉 panic、忘记 close、或在多个 goroutine 同时写入时触发竞态（比如两个协程同时往同一个 chan error 发送，但主 goroutine 只读一次）。
常见错误现象：fatal error: all goroutines are asleep - deadlock（channel 没关且没缓冲），或只拿到第一个错误就退出，但其他协程还在跑——资源泄漏、日志混乱、超时失控。
- 它默认使用
context.Background()，但实际中必须传入带超时的context.WithTimeout，否则出错后整个组卡死 -
Go方法启动协程，Wait阻塞直到所有协程结束或首个错误返回；不调用Wait就无法拿到错误 - 如果某个协程 panic，
errgroup不会捕获——仍需在协程内用recover转成 error 返回
如何正确初始化 errgroup 并设置超时
直接 new errgroup.Group{} 是错的——它没上下文控制能力，超时、取消全失效。必须用 errgroup.WithContext。
使用场景：HTTP 批量请求、数据库多表插入、文件并行处理等需要“全成功才 OK，任一失败就停”的任务。
立即学习“go语言免费学习笔记（深入）”；
- 永远从带取消/超时的 context 初始化：
g, ctx := errgroup.WithContext(context.WithTimeout(context.Background(), 5*time.Second)) - 所有子协程内部必须检查
ctx.Err() != nil，并在循环中及时退出（比如 HTTP 请求前加if ctx.Err() != nil { return ctx.Err() }） - 不要把
ctx直接传给第三方库（如http.Client）而不设 timeout，否则errgroup的超时可能被绕过
g, ctx := errgroup.WithContext(context.WithTimeout(context.Background(), 3*time.Second))
for _, url := range urls {
url := url // 避免闭包引用
g.Go(func() error {
req, _ := http.NewRequestWithContext(ctx, "GET", url, nil)
resp, err := http.DefaultClient.Do(req)
if err != nil {
return err
}
defer resp.Body.Close()
return nil
})
}
if err := g.Wait(); err != nil {
log.Println("at least one failed:", err)
}errgroup.Go 和普通 go func() 的关键区别
errgroup.Go 不是语法糖，它做了三件事：绑定 context 取消传播、串行化错误收集、保证 Wait 能感知到该协程结束。普通 go func() 做不到任何一项。
参数差异：errgroup.Go 接收一个无参、返回 error 的函数；你不能传带参数的函数，也不能忽略返回值——必须显式 return nil 或具体错误。
- 如果函数签名是
func(string) error，必须包装：g.Go(func() error { return doSomething(url) }) - 如果忘了
return，函数末尾隐式返回nil，看起来“成功”，实则掩盖逻辑缺陷 - 性能影响极小，底层只是把函数存进 slice，然后用 sync.WaitGroup 控制生命周期
为什么 Wait 返回的错误有时是 nil，但实际有协程 panic 了
errgroup 不处理 panic，panic 会直接终止协程，且不会通知 group。结果就是：其他协程继续跑，Wait 在最后一个协程结束后返回 nil，你以为全成功了。
容易踩的坑：在子协程里调用未经校验的第三方方法（比如 JSON 解析、类型断言）、或对空指针解引用，导致静默失败。
- 必须在每个
Go的函数体最外层加deferrecover：defer func() { if r := recover(); r != nil { err = fmt.Errorf("panic: %v", r) } }() - recover 后的 error 要赋给闭包外的变量（或通过返回值传出），否则依然丢失
- 别依赖日志打印来发现 panic——日志可能被并发冲掉，或根本没输出到终端
事情说清了就结束。真正难的不是用对 errgroup，而是想清楚哪些错误该传播、哪些该吞掉、哪些该重试——这得看业务，errgroup 只负责不让你漏掉第一个错误。
