Go sync.WaitGroup为并发任务补上错误汇总的工程方案

用 sync.WaitGroup 等待一批 goroutine 很方便，但它只回答“还有没有任务没结束”，不会自动保存任务返回的 error。工程上更稳妥的组合是：WaitGroup 负责生命周期计数，带容量的错误通道负责传递失败信息，最后在所有任务退出后统一汇总。这样既不会因为错误通道无人接收而卡住，也不会在主流程过早返回时丢掉其他任务的结果。

WaitGroup 只记完成数，错误需要独立出口

WaitGroup 的计数器从正数减到零时，阻塞在 Wait 的 goroutine 才会继续。Done 本质上是 Add(-1)，所以它适合表达“任务已经结束”，不适合表达“任务成功还是失败”。如果把错误写进一个共享切片，就还要为切片加互斥锁；如果直接向无缓冲通道发送，又必须保证有接收者持续消费。

启动前计数，退出时无条件 Done

下面的写法把任务名和错误包装在一起。错误通道按任务总数分配容量，意味着每个任务都可以先完成并发送错误，不必等待主 goroutine 同时读取。

package main

import (
	"errors"
	"fmt"
	"sync"
)

type taskError struct {
	name string
	err  error
}

func runAll(tasks map[string]func() error) error {
	var wg sync.WaitGroup
	errs := make(chan taskError, len(tasks)) // 缓冲容量覆盖每个任务最多一次错误

	for name, task := range tasks {
		wg.Add(1) // 先计数，再创建 goroutine，避免 Wait 提前看到零
		go func(name string, task func() error) {
			defer wg.Done() // 即使任务返回错误，也必须归还一个计数
			if err := task(); err != nil {
				errs 

这里没有在发送错误后立即返回。因为某个任务失败并不代表其他任务已经结束，先把所有结果收齐，调用方才能得到完整故障清单。任务映射的遍历顺序不固定，因此错误展示顺序也不应被当成业务排序。

关闭通道的时机决定是否会 panic 或死锁

关闭动作必须由协调者完成，而不是由某个任务完成后自行关闭。只有 wg.Wait() 返回，才能确定不会再有发送者写入。若使用无缓冲通道，则还需要独立接收循环在等待期间持续消费，否则任务可能卡在发送处，Wait 永远无法归零。

错误汇总后的判断与常见问题

调用方可以用 if err != nil 判断整批是否有失败，再用 errors.Is 或 errors.As 判断其中的具体原因。若业务要求首错即失败，仍应等待已启动任务完成清理，或者让任务主动响应 context.Context；不要用直接跳过 Wait 的方式“提速”。

为什么不能把 Add 放进 goroutine 里？

当计数器还是零时，主 goroutine 可能先执行 Wait 并立即返回，随后新 goroutine 才执行 Add。计数必须在创建任务前建立。

错误通道应该用无缓冲还是有缓冲？

任务数固定且每个任务最多发送一次时，容量设为任务数最简单；任务量动态变化时，应让接收循环与任务并行运行，避免缓冲容量成为隐形上限。

WaitGroup 能不能替代 errgroup？

不能直接替代。WaitGroup 只提供计数等待；取消、首错传播和并发协作要由通道、context 或更高层抽象补齐。本文方案适合需要保留全部任务错误的批处理场景。