errgroup虽为并发错误管理首选，但默认快速失败不适用于全量校验；需用缓冲error channel+waitgroup聚合全部结果，并显式过滤context取消错误。
errgroup 是并发错误管理的首选，但别直接用默认行为
绝大多数场景下，errgroup.Group 是最省心、最不容易出错的并发错误收集方案——它自动集成 sync.WaitGroup 语义，支持 context 取消，还能在首个错误发生时快速中止其余任务。但它的默认行为（返回第一个错误、取消其他 goroutine）并不适合所有业务。
- 如果你做的是“全量校验”类任务（比如批量导入用户，需统计成功/失败明细），
g.Wait()会提前退出，后续任务根本没机会执行，也收不到它们的错误 - 若你用了
errgroup.WithContext(ctx)，要注意ctx.Err()（如context.Canceled）会被当作普通错误返回，容易和真实业务错误混在一起上报，导致监控误报 - 务必显式判断：用
errors.Is(err, context.Canceled)或errors.Is(err, context.DeadlineExceeded)过滤掉控制流信号，只上报真正需要人工介入的错误
要汇总全部错误？用带缓冲的 error channel + WaitGroup
当必须知道每个子任务成败（比如日志审计、失败重试、成功率报表），就不能依赖 errgroup 的“快速失败”机制，而应手动聚合结果。核心是：避免无缓冲 channel 阻塞、防止并发写 slice 竞态、确保 channel 正确关闭。
- 声明
errs := make(chan error, len(tasks))，缓冲大小等于任务数，防止某个 goroutine 出错后卡在发送上 - 不要用
[]error全局收集——多个 goroutine 同时append会触发底层 slice 头部字段竞争，出现fatal error: concurrent map writes或静默丢数据 - 主协程用
for i := 0; i 按序读取，或启动一个单独 goroutine 关闭 channel 并 range 消费
goroutine panic 不会自动传播，不 recover 就是定时炸弹
这是 Go 并发中最隐蔽也最危险的问题：一个 goroutine panic 后，程序可能立刻崩溃，也可能悄无声息地少掉一路逻辑——因为 panic 默认不跨 goroutine 传递，且没有 recover 时 runtime 会直接终止整个进程。
- 不能靠外层函数 defer/recover 拦截，必须在每个独立 goroutine 入口加
defer func() { if r := recover(); r != nil { log.Printf("panic: %v\n%v", r, string(debug.Stack())) } }() - recover 里别做耗时操作（如 HTTP 请求、DB 写入），否则可能二次 panic；记录堆栈用
debug.Stack()，不是PrintStack()（后者输出到 stdout，不可控） - 如果业务要求“任一 panic 就全局停止”，可在 recover 后调用
cancel()触发 context 取消，让其他任务感知退出信号
超时与取消必须配 context，但别把 ctx.Err() 当业务错误扔给上游
并发请求不设超时，轻则拖慢整体响应，重则堆积 goroutine 导致内存暴涨。但引入 context.WithTimeout 后，常有人把 ctx.Err() 和真实错误混为一谈，结果告警系统天天被 context deadline exceeded 刷屏。
立即学习“go语言免费学习笔记（深入）”；
- HTTP 客户端必须传入带 timeout 的 ctx：
http.NewRequestWithContext(ctx, "GET", url, nil)，而不是老式http.Get - 在
errgroup.Go或自定义 goroutine 中，第一件事应该是select { case ，及时响应取消 - 错误分类处理比统一返回更重要：业务错误记 ERROR 日志并告警；
context.Canceled/context.DeadlineExceeded记 DEBUG 或 INFO 级别，不触发告警
真正难的不是写对某一段并发错误处理代码，而是始终记得：每个 goroutine 都是独立世界，错误不会自己跑回来，panic 不会喊救命，context 取消信号不是失败证据——这些认知偏差，才是线上事故最常藏身的地方。
