Go sync.WaitGroup.Go 怎样把任务生命周期交给封装

如果一组 goroutine 只需要“全部结束后再继续”，Go 1.25 提供的 sync.WaitGroup.Go 可以把任务计数、启动 goroutine 和完成扣减放在一个调用里。读者真正要记住的是：先把固定任务交给 Go，再调用 Wait；WaitGroup 只负责等待，不负责收集错误。

官方文档：https://pkg.go.dev/sync#WaitGroup.Go

对固定任务集合，优先用 wg.Go(func(){...})，不要再为同一批任务手写 Add(1) 和 Done()。任务函数必须正常返回，可能失败的业务结果要用返回值、通道或共享结果结构另行传递。

WaitGroup.Go 封装了哪三件事

官方文档把 WaitGroup.Go 定义为：在新的 goroutine 中调用函数，并把这项任务加入 WaitGroup；函数返回后，任务会从 WaitGroup 中移除。也就是说，旧写法中的三段职责被收在一起：

固定任务集合的最小写法

固定任务集合适合先遍历输入，再统一等待。下面的示例把每个名称交给一个 goroutine；Wait 放在注册任务的循环之后，避免主函数在任务尚未加入等待组前就结束。

package main

import (
	"fmt"
	"sync"
)

func main() {
	var wg sync.WaitGroup
	jobs := []string{"日报", "索引", "缓存"}

	for _, job := range jobs {
		job := job // 为闭包保存本轮任务名称，避免把循环变量语义带进任务函数。
		wg.Go(func() {
			// 任务函数只负责当前工作；返回后 WaitGroup 会自动减少计数。
			fmt.Println("处理", job)
		})
	}

	// 固定任务全部登记后再等待，主流程不会提前退出。
	wg.Wait()
}

这个写法不需要在循环前调用 Add，也不需要在闭包里写 defer wg.Done()。但 WaitGroup.Go 不会替你限制并发数、收集业务错误或取消任务；它只把“任务何时算完成”定义得更集中。

Wait、动态 Go 和任务复用的边界

当 WaitGroup 为空时，新的 Go 调用必须发生在 Wait 之前，最常见的形式就是上面的“先注册、后等待”。当等待组已经有任务时，官方文档允许由已启动的 goroutine 再调用 Go，因此可以表达树状的任务登记关系。

如果同一个等待组要用于几批互相独立的任务，必须等上一轮 Wait 返回后，再开始下一轮的 Go。不要让新旧两轮的任务计数交叉，否则读代码的人无法判断一次 Wait 等待的究竟是哪一组任务。

错误、panic 与 Add/Done 的边界

WaitGroup.Go 没有返回值，所以业务失败不能从 Wait 里取出来。可以让任务把错误写入带缓冲的通道，或写入受互斥保护的结果结构；主流程在 Wait 返回后再统一读取。若任务函数可能触发 panic，应在任务函数内部建立明确的 recover 边界并转换成错误，而不是把 panic 当成正常完成信号。官方文档明确要求传入 Go 的函数不得 panic。

仍然使用 Add/Done 的场景主要有两类：项目需要兼容没有 WaitGroup.Go 的旧 Go 版本，或已有一套外部计数协议，任务并不是由一个清晰的函数调用直接启动。除此之外，同一批固定任务不要混用两套计数方式，否则很容易重复增加或重复扣减。

快速判断清单

• 任务是否固定、只要求全部结束？是：优先用 Go 加 Wait。
• 任务是否有业务错误？单独设计错误传递，不把 Wait 当结果接口。
• 任务是否可能 panic？在任务函数内部恢复并转成可处理结果，不能放任 panic 逃出。
• 是否复用同一个等待组？上一轮 Wait 返回后再登记下一轮任务。

常见问题

WaitGroup.Go 能限制同时运行的 goroutine 数量吗？

不能。它只管理任务生命周期；并发上限需要信号量、工作池或其他独立协调结构。

用了 WaitGroup.Go 还要写 defer Done 吗？

同一项任务不要重复写。Go 已经负责函数返回后的扣减，手动再调用 Done 会破坏计数。