Go sync.WaitGroup.Go 怎么管理批量任务：启动时序、等待边界与异常收口

批量刷新缓存时，最容易出错的不是 goroutine 本身，而是任务计数和错误收口没对上：漏掉一次 Done 会让主流程一直等，提前 Wait 又可能让后续任务脱离本轮。Go 1.25 的 sync.WaitGroup.Go 把“增加计数、启动 goroutine、任务返回后扣减”绑成了一个调用，适合把这类样板收紧。

先看最小写法：计数和退出顺序一次绑定

下面的例子模拟刷新三个分片。旧写法需要同时维护 Add(1)、go 和 defer Done()；新写法只保留任务函数和等待点：

package main

import (
    "fmt"
    "sync"
)

func main() {
    var wg sync.WaitGroup
    shards := []string{"user-00", "user-01", "user-02"}

    for _, shard := range shards {
        shard := shard
        wg.Go(func() {
            fmt.Println("refresh", shard)
        })
    }

    wg.Wait()
    fmt.Println("all shards finished")
}

Go 方法内部负责把任务计数加一，并在函数返回时扣减。这样做的价值不是让代码少几行，而是减少“启动了 goroutine 却忘记计数”以及“某个分支漏写 Done”的机会。

启动时序：空组必须先 Go，非空组可以继续派生

第一次启动任务时，Wait 不能抢在 Go 前面。空组调用 Wait 会立即返回，随后才加入的任务就不再属于这次等待。

var wg sync.WaitGroup

wg.Go(loadConfig)
wg.Wait()

当 WaitGroup 已经有任务在运行时，运行中的任务可以继续调用 Go 派生子任务。一个常见场景是先并发拉取目录，再按目录中的分片继续启动工作；但派生关系要保持清楚，避免让主流程无法判断这一轮何时真正结束。

复用时也有边界：上一批任务的 Wait 返回后，才能开始下一批独立任务。不要把“上一轮还在等待”和“下一轮已经加任务”混在同一个 WaitGroup 上。

错误怎么回来：WaitGroup 只管完成，不管结果

WaitGroup.Go 的函数签名是 func()，它不会替你收集 error。批量任务需要把错误放进结果通道，并由主 goroutine 在等待结束后统一读取：

func refreshAll(shards []string) error {
    var wg sync.WaitGroup
    errCh := make(chan error, len(shards))

    for _, shard := range shards {
        shard := shard
        wg.Go(func() {
            if err := refreshShard(shard); err != nil {
                errCh 

这里的 channel 容量等于任务数，保证每个任务最多写入一次时不会因为主 goroutine 正在 Wait 而卡住。若任务会写入多条结果，应改用独立收集器或让消费端持续运行，不能只凭容量猜测不会阻塞。

panic 是硬边界：先恢复，再交给外层决定失败

官方文档明确要求传给 WaitGroup.Go 的函数不能 panic。不要把异常路径留给运气；如果任务边界必须兜底，可以在函数内部恢复，并把它转换成错误：

wg.Go(func() {
    defer func() {
        if v := recover(); v != nil {
            errCh 

恢复不是吞掉问题。错误仍要被记录、返回或触发取消；如果任务不允许恢复，就应在任务入口建立清晰的 panic 处理策略，而不是把 panic 直接传给 Go。

常见问题

WaitGroup.Go 能不能直接返回 error？

不能。它只接受 func()，错误需要通过 channel、共享结果配合互斥保护，或改用能传播错误的并发抽象处理。

调用 WaitGroup.Go 后还要写 Done 吗？

不需要，也不应该再手动写对应的 Done。重复扣减会让计数器变成负数并触发 panic。

任务函数里还能继续调用 Go 吗？

可以，只要 WaitGroup 当前不是空的。这样适合树状任务，但要控制派生规模，并确保所有子任务都属于同一轮生命周期。

Go 1.24 项目能直接编译吗？

不能把 WaitGroup.Go 当作 Go 1.24 的 API 使用。它从 Go 1.25 加入；旧项目需要继续使用 Add、go 和 Done，或先升级工具链并调整 go.mod 的版本要求。

把它放回批量任务的验收清单

• 入口处是否先启动任务，再调用 Wait？
• 错误是否有明确的收集、记录和返回路径？
• 任务函数是否保证不直接 panic，或已在边界处恢复？
• WaitGroup 是否只在上一轮 Wait 返回后复用？

如果只是等待一组无返回值的工作，WaitGroup.Go 是更紧凑的表达；如果还需要取消、首错返回和错误聚合，应该把这些职责交给更完整的并发任务抽象，别让 WaitGroup 承担它没有提供的语义。