go不提供任务编排抽象，需用errgroup.group实现带错误传播的并发协调，并结合context.context统一控制超时与取消。
Go 语言本身不提供“任务编排”或“调度系统”这类高层抽象——goroutine 和 channel 是底层协作原语，不是工作流引擎。想靠 go 关键字 + sync.WaitGroup 实现带依赖、重试、超时、状态追踪的并发任务流，很快会陷入手动管理状态和错误的泥潭。
用 errgroup.Group 控制并发任务的启动与错误传播
标准库 golang.org/x/sync/errgroup 是最轻量、最贴近 Go 哲学的并发协调工具。它解决的核心问题是：多个 goroutine 并发执行，任一出错就立即取消其余任务，并统一返回首个错误。
常见错误是直接在循环里起 go func() { ... }()，却不等结果、不处理 panic、不中断失败后的其他任务。
- 必须调用
eg.Go()启动任务，不能直接go；否则无法被Wait()捕获或取消 - 如果任务函数签名是
func() error，eg.Go()会自动处理返回值；若需传参，务必用变量捕获（避免闭包引用循环变量） -
eg.Wait()会阻塞直到所有任务完成或首个错误发生；返回的error是第一个非nil错误
eg, _ := errgroup.WithContext(ctx)
for _, url := range urls {
u := url // 避免闭包陷阱
eg.Go(func() error {
return fetch(u)
})
}
if err := eg.Wait(); err != nil {
log.Println("at least one fetch failed:", err)
}
用 context.Context 统一控制超时、取消和传递数据
没有 context 的并发任务就像没刹车的车——你无法可靠地中断正在运行的 goroutine，也无法让下游感知上游已放弃。
典型场景：HTTP 请求、数据库查询、文件读写，都应接受 ctx context.Context 参数，并在内部监听 ctx.Done()。
- 不要用
time.Sleep模拟超时；用context.WithTimeout(parent, 5*time.Second)创建带截止时间的子上下文 - 在 I/O 操作前检查
select { case ，尤其在循环或阻塞调用前 - 避免把
context.Background()到处传；从入口（如 HTTP handler）开始向下传递，保持链路清晰
别自己写 DAG 调度器：先评估是否真需要编排逻辑
多数所谓“并发任务编排”，其实只是顺序依赖（A 完成后才跑 B）、扇出（并行跑 N 个 C）、扇入（等所有 C 完成再汇总）——这些用 channel + sync.WaitGroup 或 errgroup.Group 就够了。
一旦出现条件分支（“如果 A 返回 200 才跑 B，否则跑 C”）、循环重试、任务状态持久化、跨进程恢复，说明你已经踩进工作流引擎领域，该考虑 temporal.io、cadence 或自研简易状态机，而不是硬撑着用 goroutine 拼。
- 用
chan struct{}做信号通知比轮询atomic.Bool更符合 Go 风格 - 需要“等待任意一个完成”？用
select+ 多个case - 需要“等待全部完成且收集结果”？用带缓冲的
chan Result+for i := 0; i
panic 会绕过 errgroup 和 context，必须显式 recover
errgroup.Group 只捕获返回的 error，不捕获 panic；context 也无法中断正在 panic 的 goroutine。线上服务中，未 recover 的 panic 会导致整个程序崩溃或 goroutine 泄漏。
只要任务函数可能触发 panic（比如解析不可信 JSON、调用空指针方法），就必须在 eg.Go() 包裹的函数内加 defer recover。
eg.Go(func() error {
defer func() {
if r := recover(); r != nil {
log.Printf("panic recovered: %v", r)
}
}()
return riskyOperation()
})
真正难的不是启动多少 goroutine，而是让每个 goroutine 在各种异常路径下都能释放资源、上报状态、不拖垮整体。这点容易被忽略，但决定了你的并发代码是健壮还是侥幸能跑。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
