errgroup.Group 更可靠因其内置线程安全的“首次错误即终止”逻辑，避免手动实现时的竞态、漏错、goroutine 泄漏等问题；需正确传递并使用上下文，且默认不聚合全部错误。
为什么 errgroup.Group 比自己用 sync.WaitGroup + 全局错误变量更可靠
因为 errgroup.Group 内置了“首次错误即终止”逻辑，且线程安全。自己手写时容易漏掉竞态：多个 goroutine 同时写同一个 err 变量，或忘记加锁，导致最终只保留最后一个错误、甚至 panic。
典型错误现象：err 值为空，但其实某个子任务已失败；或者程序卡住不返回，因为没调用 g.Wait() 或 goroutine 泄漏。
-
errgroup.Group的Go()方法会自动管理 goroutine 生命周期，Wait()阻塞直到所有任务完成或首个错误发生 - 默认行为是「遇到第一个非
nil错误就取消其余未启动/运行中的任务」（需配合ctx） - 若不用上下文，它仍能收集首个错误，但不会主动中断正在运行的 goroutine —— 这点常被忽略
errgroup.WithContext(ctx) 中的 ctx 到底要不要传 context.Background()
绝大多数情况不该传 context.Background()，而应复用上游传入的 ctx。否则你失去超时控制、取消传播能力，errgroup 就退化成一个带错误收集的 WaitGroup。
使用场景：HTTP handler、gRPC 方法、定时任务中需要统一控制生命周期时，必须把请求/调用上下文传进去。
立即学习“go语言免费学习笔记（深入）”；
- 传
context.TODO()或context.Background()→ 无法被外部取消，goroutine 可能永久挂起 - 正确做法：
g, ctx := errgroup.WithContext(parentCtx)，然后所有子任务都基于这个ctx做 I/O - 注意：
g.Go()内部不会自动把ctx传给你的函数，得你自己显式用 —— 比如http.NewRequestWithContext(ctx, ...)
并发任务返回多个错误时，errgroup.Group 怎么取到全部错误
它默认只暴露第一个错误（g.Wait() 返回值），不聚合。想拿到全部错误，得自己收集，不能依赖 errgroup 自动做。
常见错误现象：日志里只看到一个失败原因，但实际有 3 个服务调用都超时了，排查困难。
- 方案一：用切片 +
sync.Mutex手动收集所有错误（适合错误数少、不关心顺序） - 方案二：改用
errgroup.Group的变体，比如multierr.Append()在每个Go()回调里累积错误 - 性能影响：频繁锁写错误切片在高并发下有开销，但比丢错误强；如果只是调试用，临时加
fmt.Printf更轻量
什么时候不该用 errgroup.Group
当任务之间有强依赖、需要按序执行，或单个任务耗时极短（微秒级）、数量极大（上万）时，errgroup 反而增加调度和同步开销。
典型误用场景：循环处理 10 万个本地文件路径，每个只是 os.Stat，还硬套 errgroup。
- 纯 CPU 计算型任务（无阻塞 I/O）→ 用
runtime.GOMAXPROCS控制并行度更直接 - 需要严格顺序反馈（比如流式上传+校验）→ 应该用 channel + select 控制流程，而非靠错误传播
- goroutine 数量动态不可控（如用户输入驱动）→ 必须设限，
errgroup本身不提供并发数限制，得自己套semaphore
errgroup.WithContext。 
