errgroup.wait()仅返回第一个非nil错误，后续错误被丢弃，需在group.go()中即时判断错误类型而非等待wait()返回后处理。
errgroup.Wait() 会阻塞直到所有 goroutine 结束，但只返回第一个非 nil 错误
这是 errgroup.Group 最核心的行为逻辑。很多人误以为它会“聚合所有错误”，其实它只保留第一个传给 Group.Go() 的非 nil 错误，后续错误直接丢弃。这意味着：如果你依赖错误类型做分支处理（比如重试 io.EOF、忽略 context.Canceled），必须在调用 Group.Go() 时就做判断，不能等 Wait() 返回后再区分。
常见错误现象：errgroup.Wait() 返回了 context.DeadlineExceeded，但实际是某个子任务先返回了 sql.ErrNoRows，只是被覆盖了。
- 使用场景：http 批量请求、数据库多表查询、文件并行读取
- 关键点：所有子任务应尽早检查
ctx.Err()并提前退出，避免无意义执行掩盖真正问题 - 性能影响：不会因错误数量增加而变慢；但若某 goroutine panic，
Wait()仍会返回nil错误（需额外 recover）
Group.Go() 中的闭包变量捕获陷阱
写循环启动多个任务时，最容易漏掉变量作用域问题。例如用 for i := range urls 启动 goroutine，所有 goroutine 实际共享同一个 i 变量，最终可能全去请求 urls[len(urls)-1]。
正确做法不是加锁或 channel 同步，而是让每个 goroutine 拥有独立副本：
立即学习“go语言免费学习笔记（深入）”；
for _, url := range urls { url := url // 显式复制 g.Go(func() Error { return fetch(url) }) }- 参数差异：Go 1.22+ 支持
range循环变量自动重声明，但低版本仍需手动复制 - 容易踩的坑：用指针传参（如
&url）反而强化了问题；用index而非值更危险 - 验证方式：在 goroutine 内打日志，确认每次打印的
url是否符合预期
context.WithCancel 与 errgroup.WithContext 的配合时机
errgroup.WithContext(ctx) 创建的 group，其内部自动派生子 context，并在任意子任务返回错误时调用 cancel()。但这个 cancel 行为只影响后续新启动的 goroutine —— 已运行中的不会被中断，除非它们自己监听 ctx.Done()。
所以你不能指望 “一错就停所有”，必须主动配合：
- 每个子任务函数开头检查
ctx.Err() != nil，并快速返回 - 长耗时操作（如大文件读取、sleep）中间要定期 select
ctx.Done() - 不要把
WithContext当成“自动熔断开关”，它只是信号广播器 - 兼容性注意：Go 1.21+ 的
errgroup默认支持取消传播，旧版本需自行实现
error 类型不一致导致无法用 errors.Is 判断
当多个子任务返回不同来源的 error（比如一个来自 http.Client.Do，一个来自 json.Unmarshal），即使语义相同（如都表示“超时”），errors.Is(err, context.DeadlineExceeded) 在 Wait() 返回后可能失效 —— 因为 errgroup 内部用的是 fmt.Errorf("first error: %w", err) 包装，破坏了原始 error 链。
解决办法只有一个：别等 Wait()，在每个 Go() 里自己判断并记录：
g.Go(func() error { err := doSomething() if errors.Is(err, context.DeadlineExceeded) { log.Warn("timeout ignored") return nil // 或自定义忽略逻辑 } return err })- 为什么这样做：绕过包装层，保持 error 原始结构
- 容易忽略的地方：log.Fatal 或 panic 会跳过 error 检查，导致本该忽略的错误中断整个流程
- 性能提示：频繁调用
errors.Is开销极小，可放心用于关键路径
真正难的从来不是怎么启动并发，而是怎么让它们在出错时既不互相干扰，又不掩盖真相。errgroup 把“谁先错”的问题简化了，但没解决“错得对不对”的问题。