errgroup 是为“任一 goroutine 出错即取消其余任务”设计的同步原语，封装 waitgroup 和 context，自动处理取消传播与错误收集；手动用 waitgroup 加全局 Error 变量会导致竞态、漏判和无法及时中断。
ErrGroup 是什么，为什么不用 wait.Group + 全局 error 变量
ErrGroup 不是语法糖，而是为「并发中任意一个 goroutine 出错就提前取消其余任务」设计的同步原语。它内部封装了 sync.WaitGroup 和 context.Context，自动处理取消传播和错误收集——而自己用 wait.Group 配全局 error 变量，会面临竞态、漏判、无法及时中断的问题。
常见错误现象：nil pointer dereference（因为多个 goroutine 同时写同一个 err 指针）、context canceled 被忽略、任务明明失败却等到全部结束才返回。
- 必须用
errgroup.Group而非裸sync.WaitGroup处理带错误的并发任务 -
errgroup.WithContext返回的 group 会继承父 context；若传入context.background()，则无法响应取消信号 - 所有子任务必须用
group.Go启动，不能直接 go func() —— 否则 cancel 不会传播，错误也不会被捕获
group.Go 的函数签名必须返回 error
group.Go 只接受 func() error 类型函数，这是硬性约束。它靠这个返回值判断是否出错，并决定是否调用 cancel()。如果函数不返回 error，编译直接报错：cannot use … (type func()) as type func() error。
使用场景：http 请求、文件读写、数据库查询等可能失败的操作。
立即学习“go语言免费学习笔记（深入）”；
- 不要包装成
func() { ... }再丢给group.Go，得显式返回error - 若原有逻辑不返回 error，需补一层适配，比如：
func() error { doSomething(); return nil } - 注意：返回
nil表示成功；返回非nil错误会触发整体取消（除非用group.TryGo）
TryGo 和 Go 的区别，什么时候该用 TryGo
group.Go 会阻塞直到有空闲 goroutine（默认限流为无限制，但底层仍走 channel 控制），而 group.TryGo 尝试提交任务，若当前已达到并发上限（如设置了 semaphore），则立刻返回 false，不执行函数。
性能影响：在高并发且资源受限场景（如限制同时最多 10 个 HTTP 请求），TryGo 可避免排队等待，更适合做“尽力而为”的批量操作。
-
TryGo不会自动取消其他任务，即使它自己失败或被跳过 - 若没调用
errgroup.WithContext，TryGo提交的任务不会受 context 控制 - 错误仍需手动检查返回值：
if !group.TryGo(func() error { ... }) { log.Println("skipped") }
Wait 返回的 error 容易被误判为“所有子任务都失败”
group.Wait() 返回的是「第一个发生的非 context.Canceled 错误」，不是聚合结果。很多人以为它代表最终状态，其实只要有一个子任务返回非取消类错误（比如 io.EOF、sql.ErrNoRows），Wait 就立刻返回它，其余任务可能还在跑或已被取消。
容易踩的坑：把 group.Wait() 当作“汇总所有错误”的入口，然后试图遍历或格式化多个 error——它根本没存那些。
- 需要完整错误列表？得自己用切片 + mutex 收集，
errgroup不提供 -
context.Canceled和context.DeadlineExceeded是取消原因，不是业务错误，常需过滤处理 - 若所有子任务都返回
nil，Wait()返回nil；哪怕其中几个被 cancel 掉，只要没抛业务错误，就还是nil
真正难处理的，是那个隐含假设：「所有 goroutine 都该有对等的错误语义」。现实里有的要重试，有的要忽略，有的要转成 warning——ErrGroup 不帮你做决策，只负责同步和短路。