WaitGroupGo启动受控并发任务

如果项目使用 Go 1.25 或更高版本，启动一组需要统一等待的 goroutine，可以直接写 sync.WaitGroup.Go。它把“增加任务计数、启动 goroutine、任务结束后减少计数”合并成一个调用，适合批量抓取、并行处理和后台任务编排。

但要先划清边界：WaitGroup.Go 只负责跟踪任务并等待任务结束，不会限制同时运行的任务数量。需要限流时，还要配合信号量、worker pool 或专门的调度器。

迁移的最小写法是把 wg.Add(1)、go func 和 defer wg.Done() 收拢为 wg.Go(func() { ... })，保留 wg.Wait()。传入的函数不能 panic；当 WaitGroup 为空时，应先完成 Go 调用，再调用 Wait。

官方资料：https://go.dev/doc/go1.25、https://pkg.go.dev/sync

先确认这次迁移解决什么问题

WaitGroup 的职责是维护一个任务计数器：任务开始时计数增加，任务结束时计数减少，Wait 阻塞到计数归零。旧写法把这三个动作分散在多个位置，最容易出现忘记 Done、Add 放错位置，或者启动逻辑和清理逻辑不在同一段代码里的问题。

Go 1.25 在 sync.WaitGroup 上增加了 Go(f func())。官方文档说明，它会在新的 goroutine 中调用 f，并在 f 返回时移除对应任务；因此它更适合表达“这个函数就是一个受 WaitGroup 管理的任务”。

旧写法怎样平移到 WaitGroup.Go

假设一个批处理器要并发处理一组文件，旧代码通常需要手动维护计数：

package main

import "sync"

func process(name string) {
	// 这里代表一个独立任务；真实项目中可以替换成文件或请求处理。
}

func runOld(names []string) {
	var wg sync.WaitGroup
	for _, name := range names {
		wg.Add(1) // 启动前增加一个任务计数。
		go func(name string) {
			defer wg.Done() // 无论函数从哪里返回，都要归还任务计数。
			process(name)
		}(name)
	}
	wg.Wait() // 等待所有任务归还计数。
}

迁移后，把任务函数直接交给 Go：

func runNew(names []string) {
	var wg sync.WaitGroup
	for _, name := range names {
		name := name // 明确保存本轮任务的参数，兼容旧项目的循环变量语义。
		wg.Go(func() {
			process(name) // Go 会在函数返回时自动减少任务计数。
		})
	}
	wg.Wait() // 仍由 Wait 等待任务计数归零。
}

这里真正减少的是计数管理的分散程度，不是 goroutine 的数量。遍历一万个元素就调用一万个 wg.Go，仍然可能同时创建一万个任务。

Go 调用和 Wait 的时序要分清

当 WaitGroup 当前为空时，官方语义要求 Go 发生在 Wait 之前。最清晰的结构仍然是“先提交任务，后等待”：

func runBatch(tasks []func()) {
	var wg sync.WaitGroup
	for _, task := range tasks {
		task := task // 避免闭包引用不明确的外部变量。
		wg.Go(func() {
			task() // 任务返回后由 WaitGroup.Go 自动完成计数回收。
		})
	}
	wg.Wait() // 所有 Go 调用完成后再等待整批任务。
}

如果 WaitGroup 已经有未完成任务，新的 Go 可以在另一个受管理的任务中继续提交子任务。可是，当一轮任务已经被 Wait 等完并准备复用同一个 WaitGroup 时，要等上一次 Wait 返回后，再开始下一轮。

迁移时不要把 wg.Wait() 放进提交循环，也不要在一个空 WaitGroup 上先 Wait、再从另一个 goroutine 里补 Go。后者会让等待和任务提交失去清晰的先后关系。

panic、错误和取消仍要自己设计

WaitGroup.Go 不会替任务处理错误。更重要的是，传入的函数不能 panic。要是任务可能触发 panic，应在任务内部建立明确的恢复和上报策略；不能以为 WaitGroup 会替你捕获异常。

type Result struct {
	Name string
	Err  error
}

func runWithResults(names []string) []Result {
	var wg sync.WaitGroup
	results := make(chan Result, len(names)) // 缓冲区避免任务返回时立即卡在发送上。

	for _, name := range names {
		name := name
		wg.Go(func() {
			// 任务内部负责把错误转换成结果；不要让 panic 穿过 Go 的函数边界。
			results 

示例中的 handle 代表业务函数。若还需要取消未完成任务，应让任务接收 context.Context 并主动检查取消信号；WaitGroup 只知道任务是否结束，并不知道任务为什么结束。

需要限并发时，给 WaitGroup 加一个容量边界

“受控并发”如果指的是“最多同时运行 N 个任务”，仅使用 WaitGroup 不够。可以用带缓冲通道做信号量：任务开始前占用一个槽位，返回时释放槽位；WaitGroup 仍负责等待全部任务。

func runLimited(names []string, limit int) {
	if limit 

这个版本的上限作用在提交端：当槽位耗尽，循环不会继续创建新的 goroutine。若任务需要响应取消，还应把占用槽位的发送改成带 select 的上下文版本，并为取消后的提交路径设计清理逻辑。

迁移前后的检查清单

几个容易混淆的问题

WaitGroup.Go 能返回任务错误吗？

不能。它的签名是 Go(f func())，没有返回值。可以通过结果通道、错误收集器或项目中的 errgroup 风格抽象传递错误。

WaitGroup.Go 能限制 goroutine 数量吗？

不能。它只管理计数和等待；要限制同时执行的任务数，需要信号量、worker pool 或其他调度策略。

旧项目必须立刻改成 WaitGroup.Go 吗？

不必。旧写法仍然适用于需要兼容 Go 1.24 及更早工具链的项目。若项目已统一到 Go 1.25 以上，并且任务边界正好是一个无返回值函数，迁移通常能让计数和清理关系更集中。

最终可以把这次迁移记成一句话：WaitGroup.Go 让任务登记更不容易漏写 Done，Wait 负责等完，信号量或 worker pool 才负责限制并发。把三种职责分开，批量并发代码会更容易维护。