errgroup.wait() 阻塞等待所有 go() 提交的 goroutine 结束，包括重试中的；重试须在单个 go() 函数内闭环管理，需显式 return 错误或 nil，panic 必须 recover 并转为 Error，context 超时仅在外层设置一次，限流需配合 semaphore，日志需标识任务 id 与重试序号。
errgroup.Wait() 会阻塞直到所有 goroutine 完成，包括重试中的
很多人以为 errgroup.Group 的 Wait() 只等“首次启动”的 goroutine，其实它等的是所有通过 Go() 提交的任务——哪怕你在内部手动循环重试，只要没退出 goroutine，就一直算“还在运行”。这会导致：任务明明失败了、重试也放弃了，但主流程卡在 Wait() 不返回。
- 重试逻辑必须封装在单个
Go()调用的函数体内，不能靠外部循环反复调用eg.Go() - 每个任务的重试次数、间隔、是否跳过后续重试，都要在闭包里自己管理，
errgroup不参与重试控制 - 如果某次重试成功，记得用
return nil退出 goroutine；如果彻底失败，也要return err，否则Wait()永远不结束
重试时 panic 会导致整个 errgroup 崩溃
errgroup.Group 对 panic 没有恢复机制。一旦某个任务 goroutine panic，Wait() 会直接抛出 panic: send on closed channel 或更隐蔽的 fatal error: concurrent map writes —— 因为底层共享的 error channel 已被关闭。
- 所有网络调用、json 解析、第三方库调用，都得套
defer func() { recover() }() - 不要依赖
recover()来“继续重试”，而是用它兜底并显式返回错误：return fmt.Errorf("panic during retry: %v", r) - 测试时故意让一个任务 panic，看主流程是否还能拿到其他任务的正确结果和错误类型
context.WithTimeout 和重试时间容易叠加错乱
用 context.WithTimeout(parent, totalTimeout) 包住整个 errgroup 是对的，但如果你在每个重试里又新建子 context（比如 context.WithTimeout(ctx, perRetryTimeout)），实际超时行为会变成“总时间 = 最大重试次数 × perRetryTimeout”，而不是你想要的“所有重试加起来不超过 totalTimeout”。
- 只在最外层用一次
context.WithTimeout，传给每个 goroutine 复用 - 重试间隔用
time.Sleep()，别用带 timeout 的 http.Client 或数据库查询去“凑”重试逻辑 - 检查
ctx.Err()应该放在每次重试前（不是仅在第一次），否则可能白跑好几轮才退出
并发数控制 + 重试 = 实际 goroutine 数远超预期
errgroup.WithContext 本身不控制并发，要限流得配 semaphore 或带缓冲的 channel。但很多人忽略：一个任务失败后重试 3 次，等于它占用了 3 个“slot”，而别的任务还在排队——最终并发峰值可能是设置值的数倍。
立即学习“go语言免费学习笔记（深入）”；
- 用
golang.org/x/sync/semaphore在每次eg.Go()前 acquire，重试中不再重复 acquire - 把重试逻辑写成循环，而不是递归调用或嵌套
eg.Go() - 日志里打上任务 ID 和重试序号（如
"task-123-retry-2"），否则线上查问题时分不清是同一个任务反复失败，还是不同任务撞了
重试和并发组合起来，最难的不是写代码，而是厘清“谁负责取消、谁负责计时、谁负责释放资源”。漏掉任意一环，轻则超时不准，重则 goroutine 泄漏、内存暴涨。