Go sync.WaitGroup.Go 如何管理任务启动与等待：闭包捕获和 panic 边界

批量处理文件、订单或消息时，最容易留下的并发 bug 不是“少写了一个 goroutine”，而是任务已经启动，主流程却提前返回，或者闭包读到了变化中的循环变量。Go 1.25 的 sync.WaitGroup.Go 把计数、启动和完成收口合并起来，能减少一类样板代码，但它仍然只负责等待，不负责错误传递和取消。

把每个任务的输入在启动前固定下来，用 wg.Go 启动，主流程只在所有任务完成后执行 wg.Wait；任务函数不能 panic，需要由任务内部转成可记录的失败结果。

先把批处理流水线拆成启动、处理和收口

假设服务每轮读取一批 Job，处理结果写入 channel，最后由汇总阶段关闭结果通道。这里的关键顺序是：先让每个 Job 进入 loadJob，再由 wg.Go 启动任务，主 goroutine 调用 wg.Wait 后才执行 close(results)。

type Job struct {
    ID int
}

func runBatch(jobs []Job) []error {
    results := make(chan error, len(jobs))
    var wg sync.WaitGroup

    for _, job := range jobs {
        job := job
        wg.Go(func() {
            results 

WaitGroup.Go 等价于把“增加计数、启动 goroutine、函数返回后 Done”绑定在一起。它没有改变结果 channel 的语义：缓冲区仍要足够，或者必须另有消费者，否则任务可能卡在写入结果时，wg.Wait 也就永远等不到返回。

循环里的闭包，先固定 job 再交给 wg.Go

上面的 job := job 不是装饰。闭包会在稍后运行，如果直接引用循环变量，任务看到的输入就不再是“创建任务那一刻的值”。局部副本让 wg.Go 绑定到当前迭代的 job，这比在任务内部猜测索引更容易审查。

for _, n := range []int{1, 2, 3} {
    job := Job{ID: n}
    wg.Go(func() {
        results 

如果任务只需要一个值，也可以把值作为参数传入函数字面量。判断标准很简单：图片和代码里的 job、n 都应当代表本轮要处理的固定输入，而不是共享可变状态。

WaitGroup.Go 的门禁：Wait、复用和 panic 要分别看

官方文档明确要求传给 WaitGroup.Go 的函数不能 panic。需要保护边界时，可以在任务函数最外层用 defer 做恢复并写入错误结果，但恢复逻辑必须有明确的记录格式，不能悄悄吞掉异常。

失败处理不要伪装成 WaitGroup 的能力

wg.Wait 的结果只有“所有任务结束”。它不会告诉你哪一个任务失败，也不会因为一个任务返回 error 就停止其他任务。批处理要拿到失败明细，可以让每个任务把带有 Job.ID 的结果写入 channel；如果还需要首错取消，就把 context.Context 作为独立的控制通道。

type Result struct {
    JobID int
    Err   error
}

func handle(job Job, results chan

这段结构把三件事分开：WaitGroup 负责生命周期，Result 携带业务失败，context.Context 承担取消信号。分开后，日志里才能回答“任务结束了吗”“任务为什么失败”“其他任务是否收到取消”。

上线前用一个可重复检查确认收口顺序

最小验收可以固定三组输入：空列表、单个失败任务、多个任务并发写结果。检查 close(results) 是否发生在 wg.Wait 返回之后，检查每个 Result.JobID 是否对应原始输入，再用 go test -race 观察闭包和结果收集是否存在数据竞争。

如果项目仍支持 Go 1.24 或更早版本，不能直接编译 WaitGroup.Go。此时保留显式的 wg.Add(1)、defer wg.Done() 写法，等最低版本提升后再迁移；这属于兼容决策，不是把新方法包一层就能自动解决的问题。

相关问题

WaitGroup.Go 会收集任务 error 吗？

不会。它只管理任务计数和等待，错误需要通过结果 channel、共享结果结构或其他明确协议传回。

WaitGroup.Go 能取消还没完成的任务吗？

不能。用 context.Context 或业务停止信号传递取消意图，并让任务主动检查。

任务函数发生 panic 会怎样？

API 文档要求任务函数不能 panic。需要容错时，在任务边界恢复并记录为失败，不能把异常留给 WaitGroup 处理。

WaitGroup.Go 适合收紧“任务启动到结束”的生命周期，不适合替代错误聚合、取消和重试框架。先固定闭包输入，再确认 wg.Wait 与 close(results) 的顺序，迁移就有了可验证的边界。