ErrGroup 不能直接取消已启动的 goroutine，因其不管理 goroutine 生命周期，仅收集错误和等待；必须在每个 group.Go() 函数内显式监听 ctx.Done() 并在阻塞点主动退出。
ErrGroup 为什么不能直接取消已启动的 goroutine
因为 errgroup.Group 本身不管理 goroutine 的生命周期，它只负责收集错误和等待完成。调用 group.Go() 启动的任务，如果内部没主动监听 ctx.Done()，就算外部 context 已 cancel，goroutine 仍会继续跑完甚至卡死。
常见错误现象：调用 group.Wait() 阻塞住，日志显示某个任务明明该超时了却没退出。
- 必须在每个
group.Go()传入的函数里显式检查ctx.Err() != nil - 不能只靠
group.WithContext(ctx)就以为万事大吉 —— 它只影响后续Go()启动时的默认 context，不注入到你的函数逻辑里 - IO 操作（如
http.Get、time.Sleep）要优先用带 context 的版本，比如http.NewRequestWithContext、time.AfterFunc配合ctx.Done()
如何让每个 goroutine 真正响应 cancel
核心是把父 context 透传进去，并在关键阻塞点做 select 判断。不是“加个 ctx 参数”就完事，得在可能长时间运行的位置主动退出。
使用场景：并发请求多个下游服务，其中一个超时后应立刻中止其余未完成请求。
立即学习“go语言免费学习笔记（深入）”；
- 每个
group.Go()函数签名必须接收context.Context，且第一件事是select { case - 网络请求务必用
http.DefaultClient.Do(req)替代http.Get()，并确保req是通过http.NewRequestWithContext(ctx, ...)创建的 - 自定义阻塞操作（如轮询、数据库查询）需在循环开头加
if ctx.Err() != nil { return ctx.Err() }
示例片段：
group.Go(func() error {
select {
case <-time.After(2 * time.Second):
return nil
case <-ctx.Done():
return ctx.Err()
}
})context.WithCancel 和 errgroup.WithContext 的配合陷阱
很多人误以为 errgroup.WithContext(ctx) 返回的新 group 能自动传播 cancel，其实它只是把 ctx 存下来供后续 Go() 内部使用 —— 但你仍得手动把那个 ctx 传给每个子任务，或在子任务里用 groupCtx := groupCtx（即 group 自带的 ctx）。
性能影响：额外一次 context.Value 查找开销可忽略；但若漏传或错用，会导致 cancel 完全失效，比性能问题更严重。
- 推荐写法：
g, gCtx := errgroup.WithContext(ctx)，然后所有g.Go()函数里统一用gCtx做判断和传递 - 不要混用：比如外部用
ctx启动 group，内部又自己 new 一个context.WithCancel(ctx)，容易导致 cancel 信号断链 - 注意嵌套：如果子任务还要再启 sub-group，必须把当前
gCtx传下去，而不是原始ctx
error 处理和上下文信息丢失的典型表现
当多个 goroutine 并发失败时，group.Wait() 只返回第一个非 nil error，其余错误被吞掉 —— 这会让调试变得困难，尤其当你想区分“超时”和“连接拒绝”这类语义差异时。
容易踩的坑：直接用 fmt.Errorf("failed: %w", err) 包裹，却没保留原始 context 的 deadline 或 cancel 原因。
- 用
errors.Join()（Go 1.20+）聚合所有错误，再结合ctx.Err()判断是否属于 cancel 场景 - 避免覆盖原始 error：比如
return fmt.Errorf("fetch user: %w", err)比return errors.New("fetch user failed")更利于排查 - 日志中打印
ctx.Err()类型（context.DeadlineExceededvscontext.Canceled），能快速定位是超时还是主动终止
复杂点在于：cancel 不等于失败，但很多业务逻辑把它当失败处理。真正需要的是区分「任务被中断」和「任务执行出错」——这得靠 error 类型判断，而不是只看 group.Wait() != nil。
