ErrGroup.Run 在 context 被取消后 panic context.Canceled 是正常设计行为，需调用前检查 ctx.Err() == nil；优先使用 GoContext 处理可取消 IO 任务，Go 仅适用于无取消需求的纯 CPU 计算。
ErrGroup.Run 启动任务时 panic：context.Canceled 是正常现象
当 ErrGroup 关联的 context 被取消（比如超时或手动调用 cancel()），后续再调用 eg.Run() 会直接 panic 报 context.Canceled。这不是 bug，而是设计使然——ErrGroup 认为上下文已失效，拒绝接收新任务。
常见错误现象：panic: context canceled 出现在 eg.Run() 调用处，但你没显式 cancel；其实是上游 context 已过期（例如 context.WithTimeout 到期）。
- 务必在调用
eg.Run()前检查ctx.Err() == nil，否则直接 panic - 不要复用已取消的 context 创建新 ErrGroup；每次并发批次应配独立 context
- 如果需要“尽力执行”，改用
eg.Go()+ 手动判断 ctx 是否有效，而非依赖Run()
Go() 和 GoContext() 的选择：何时必须用 GoContext
ErrGroup.Go() 只接受无参函数，不感知 context；ErrGroup.GoContext() 显式传入 ctx，并在内部自动监听取消信号、提前中止 goroutine。两者行为差异直接影响错误传播的及时性。
使用场景：HTTP 请求、数据库查询、文件读写等可能阻塞且支持 context 取消的操作。
立即学习“go语言免费学习笔记（深入）”；
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 只要任务函数本身接受
context.Context参数，一律优先用eg.GoContext() -
eg.Go()适合纯 CPU 计算、无 IO、不响应取消的短任务；它不会主动检查 context 状态 - 混用二者时，
Go()启动的任务可能继续运行，即使 context 已取消，导致资源泄漏或错误被掩盖
示例：
eg.GoContext(func(ctx context.Context) error {
return http.GetWithContext(ctx, "https://api.example.com/data")
})
errgroup.Wait 返回 nil 却仍有子任务失败：检查是否漏了 err 检查
errgroup.Wait() 返回 nil 表示「所有启动的任务都完成了，且没有非 nil 错误被报告」。但它不保证每个 goroutine 都真正执行完毕——如果某个 Go() 任务 panic，而你没 recover，整个程序就崩了，根本走不到 Wait()。
更隐蔽的问题是：多个任务返回错误，但 ErrGroup 只保留第一个非 nil 错误（按完成顺序），其余错误被丢弃。
- 务必在每个
Go()或GoContext()的闭包里显式处理并返回 error，不要只 log - 不要假设
Wait()返回非 nil 就代表“有错”，返回 nil 也不代表“全成功”——要结合业务逻辑确认关键路径是否执行 - 若需收集全部错误，不用
errgroup.Group，改用自定义 channel + sync.WaitGroup + slice 存储
WithContext 和 WithCancel 的区别：别在 HTTP handler 里用 WithCancel
errgroup.WithContext(ctx) 返回的 Group 共享原 context；errgroup.WithCancel(ctx) 内部额外调用 context.WithCancel(ctx)，提供一个可主动取消的子 context。但这个取消能力不是免费的。
性能影响：每次 WithCancel() 都新建 context 节点，增加调度开销；在高并发 HTTP handler 中频繁创建，会放大 GC 压力。
- 绝大多数场景用
errgroup.WithContext(r.Context())就够了，让请求生命周期自然管理 - 仅当你需要「主动终止部分子任务而不影响父 context」时才用
WithCancel()，例如长轮询中收到客户端断连信号 - 用
WithCancel()后记得调用返回的cancel()函数，否则子 context 泄漏，goroutine 无法退出
ErrGroup 不是错误收集器，它是错误传播协调器。它不帮你捕获 panic，也不合并多个 error，更不保证所有 goroutine 都能优雅退出——这些都得靠你对 context 的理解和对任务边界的清晰划分。
