Go 1.25 sync.WaitGroup.Go 如何把任务失败传回主流程：并发收口与退出时机

批量校验订单时，最容易出现一种“看起来等完了，实际上不知道哪一步失败”的代码：多个 goroutine 被启动，主流程调用 wg.Wait()，但任务里的 error 没有出口。Go 1.25 的 sync.WaitGroup.Go 能把“启动并计数、结束后扣减”合在一起，却不会替你收集错误。

WaitGroup.Go 只负责任务生命周期；要把失败传回主流程，应让每个任务写入 taskResult，主 goroutine 再统一读取并决定是否退出。

先把两个职责分开：WaitGroup 等结束，结果通道传错误

官方文档把 WaitGroup.Go 定义为“启动一个 goroutine 并加入 WaitGroup，函数返回时移除任务”。它的函数签名是 Go(f func())，没有返回值，也没有内置的错误聚合策略。这个限制反而让并发边界更清楚：等待用 wg，结果用 results。

type taskResult struct {
    name string
    err  error
}

results := make(chan taskResult, len(jobs))
var wg sync.WaitGroup

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

这里的 taskResult 同时保留任务名和错误值。成功任务发送 err: nil，主流程就能区分“任务完成但通过”和“任务完成但失败”，不必依赖日志文本猜测。

为什么结果通道要按任务数留容量

如果 results 是无缓冲通道，任务发送结果时必须等主 goroutine 同时接收。主流程若先调用 wg.Wait()，而任务又卡在 results ，等待就永远无法归零，形成自锁式等待。

把容量设为 len(jobs) 后，每个任务最多写入一次结果，任务可以先完成并让 wg.Wait() 返回。容量不是为了无限堆积消息，而是覆盖这段有限的“生产者先结束、消费者后汇总”窗口。

用等待 goroutine 收口，再由主流程处理首个失败

主流程既要等待所有任务完成，又要知道什么时候可以安全地读完结果，可以让一个专门的收口 goroutine 等待并关闭通道：

go func() {
    wg.Wait()
    close(results)
}()

var firstErr error
for result := range results {
    if result.err != nil && firstErr == nil {
        firstErr = fmt.Errorf("%s: %w", result.name, result.err)
    }
}
if firstErr != nil {
    return firstErr
}
return nil

主 goroutine 从 results 持续读取，直到 close(results) 让 range 结束。即使第一个失败已经出现，也建议继续排空结果；这样其他任务有机会正常返回，收口逻辑也只有一个出口。

失败处理不能偷换成 panic 或提前退出

WaitGroup.Go 的文档明确要求传入的函数不能 panic。若校验逻辑可能触发 panic，应在任务函数内部用 defer 和 recover 把它转成 taskResult.err，并保留任务名；不要让 panic 穿透 goroutine 边界。

wg.Go(func() {
    result := taskResult{name: job.Name}
    defer func() {
        if value := recover(); value != nil {
            result.err = fmt.Errorf("panic: %v", value)
        }
        results 

若业务要求“首错后立即取消剩余任务”，还需要额外的 context.Context 协作，让 validate 主动检查取消信号。WaitGroup.Go 本身不会取消任务，也不会因为某个结果失败而停止其他 goroutine。

常见问题：WaitGroup.Go 的错误回传边界

WaitGroup.Go 能直接返回 error 吗？

不能。它接受 func()，错误要通过通道、共享结果结构或专门的 errgroup 类方案传回。

为什么不能让最后一个任务关闭 results？

任务本身无法安全判断自己是否最后一个完成；由 wg.Wait 返回后统一 close(results)，才能保证不会再有发送者。

发现首错后能直接 return 吗？

可以先记录首错，但应继续接收结果并等待收口。直接返回会让仍在运行的任务失去结果接收者，除非它们使用了足够容量且有明确取消与回收方案。

Go 1.24 项目能直接使用 WaitGroup.Go 吗？

不能。该方法从 Go 1.25 起加入标准库；旧版本继续使用 Add、Done 和 Wait，并保持相同的结果通道设计。

上线前检查这四个并发收口点

• 任务函数是否有明确的 taskResult 出口，且每个任务最多发送一次？
• results 是否至少能容纳任务总数，或是否有持续接收者？
• 是否只有等待全部任务结束的一方执行 close(results)？
• 失败后是否仍能完成结果排空、取消协作和 goroutine 回收？

把 WaitGroup.Go 看成生命周期工具，错误回传就不会再被“等待结束”这个动作掩盖。并发代码真正要验收的不是主流程有没有调用 Wait，而是每个任务的结果能否在关闭通道前抵达唯一的汇总点。