Go WaitGroup.Go 任务函数如何安全传递参数

使用 sync.WaitGroup.Go 在循环里启动任务时，最稳妥的做法是先把当前迭代需要的输入绑定到独立的局部值，再让闭包捕获这个值。不要把一个会继续变化的循环变量、可变指针或共享切片元素直接当成所有任务的共同输入。

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

先在循环体内固定本轮输入

WaitGroup.Go 的参数类型是无参函数，所以常见写法是让闭包捕获循环中的任务。关键不在于把 Go 换成另一个并发 API，而在于闭包捕获的变量是否代表本轮任务。

package main

import "sync"

type Job struct {
    ID  int
    URL string
}

func handle(job Job) {
    // 这里代表一个只读任务；真实项目中可替换为请求、解析或落库逻辑。
    println(job.ID, job.URL)
}

func main() {
    jobs := []Job{
        {ID: 101, URL: "https://example.test/a"},
        {ID: 102, URL: "https://example.test/b"},
        {ID: 103, URL: "https://example.test/c"},
    }

    var wg sync.WaitGroup
    for _, job := range jobs {
        job := job // 为本轮建立局部副本，闭包不会依赖后续迭代的变量变化。
        wg.Go(func() {
            handle(job)
        })
    }
    wg.Wait() // 等待任务计数归零后再离开 main。
}

这一行 job := job 看起来像重复声明，实际是在循环体内创建新的局部绑定。它把“本轮要处理的值”从“循环变量的来源”中分离出来，后面的闭包只引用这份副本。即使代码还要兼容较旧的 Go 模块语义，这种写法也容易读懂。

闭包捕获和 WaitGroup.Go 解决的是两件事

闭包捕获决定任务函数以后读取哪个变量；WaitGroup.Go 负责把无参函数放入新的 goroutine，并把任务计数纳入 Wait 的等待范围。它不会替你把循环变量转换成函数参数，也不会替你保护可变对象。

如果把一个会被后续迭代持续写入的变量直接放进闭包，问题属于参数绑定；如果每轮已经拿到了独立值，但忘记调用 Wait，问题属于生命周期管理。分开看这两个边界，排查时就不会把“任务执行太快或太慢”误判为参数传错。

package main

import "sync"

func runOne(wg *sync.WaitGroup, job Job) {
    wg.Go(func() {
        // job 是函数参数，每次调用 runOne 都有独立的值绑定。
        handle(job)
    })
}

func startJobs(jobs []Job) {
    var wg sync.WaitGroup
    for _, job := range jobs {
        runOne(&wg, job) // 用普通函数参数把值边界写在调用点。
    }
    wg.Wait()
}

把参数交给 runOne 是另一种清晰方案：循环只负责遍历和调用，闭包只捕获 runOne 的值参数。它尤其适合任务启动逻辑需要复用、测试或增加统一日志时使用。

按值传递、传函数参数和传指针怎么选

只读任务优先传值。结构体较大时，也不要先凭直觉把指针放进共享切片；先问清楚任务是否必须修改原对象、修改是否允许并发发生，以及谁负责保证互斥。参数安全的第一目标是让每个任务的输入边界可见。

package main

import "sync"

func startReadOnly(jobs []Job) {
    var wg sync.WaitGroup
    for i := range jobs {
        job := jobs[i] // 复制结构体值，任务之间不会共享这个局部绑定。
        wg.Go(func() {
            handle(job)
        })
    }
    wg.Wait()
}

func startWithSharedPointer(jobs []*Job) {
    var wg sync.WaitGroup
    for _, job := range jobs {
        job := job // 只复制指针变量；底层 Job 仍可能是同一个可变对象。
        wg.Go(func() {
            // 只有在 handle 不并发修改 Job，或已有明确同步时才这样做。
            handle(*job)
        })
    }
    wg.Wait()
}

上面的两种代码都能让闭包拿到本轮的变量，但语义不同：第一段复制的是 Job 的值，第二段复制的是指针。第二段不会自动消除底层对象的共享；如果多个任务通过指针写同一对象，仍然需要锁、通道或其他同步设计。

多字段任务用值对象收住输入

当任务需要 ID、路径、超时和重试次数等多个字段时，可以在循环中组装一个任务输入值。这样闭包捕获的是一个完整对象，而不是分别捕获多个可能在循环中变化的变量。

package main

import (
    "sync"
    "time"
)

type TaskInput struct {
    ID      int
    Address string
    Timeout time.Duration
    Retry   int
}

func execute(input TaskInput) {
    // 函数只读自己的输入，避免把循环状态隐藏在全局变量中。
    _ = input
}

func start(inputs []TaskInput) {
    var wg sync.WaitGroup
    for _, input := range inputs {
        input := input // 先固定完整值，再交给无参任务函数。
        wg.Go(func() {
            execute(input)
        })
    }
    wg.Wait()
}

这种写法的好处是接口稳定：未来增加字段时，调用点仍然只需要组装 TaskInput，任务函数的输入也能被单独测试。若任务确实要回写状态，可以把结果通过带缓冲的 channel 送回协调 goroutine，再集中更新共享集合。

Wait、Go 版本和 panic 边界别混在一起

WaitGroup.Go 从 Go 1.25 起提供。使用它的模块需要满足对应的工具链要求；如果项目仍需兼容更早版本，可以继续用 Add、go 和 Done，并把参数写成显式函数参数。

官方文档还明确要求传给 Go 的函数不能 panic。它不是错误收集器，也不会自动把 panic 变成普通错误。如果业务边界允许恢复，应在任务内部明确记录或回传恢复结果，而不是静默吞掉异常：

func startSafely(jobs []Job) {
    var wg sync.WaitGroup
    for _, job := range jobs {
        job := job // 先固定本轮值，再处理任务内部的异常边界。
        wg.Go(func() {
            defer func() {
                if recovered := recover(); recovered != nil {
                    // 生产代码应把 recovered 写入日志或错误通道，不能无声丢弃。
                    println("task panic recovered")
                }
            }()
            handle(job)
        })
    }
    wg.Wait()
}

另外，空的 WaitGroup 应先完成任务注册，再调用 Wait。如果已有任务在运行，新的 Go 可以由任务继续注册子任务；但一组任务完成后要复用同一个 WaitGroup，就应等前一次 Wait 返回后再开始下一组。

常见问题

WaitGroup.Go 能直接传入带参数的函数吗？

不能。它的签名是 Go(f func())，可以用闭包捕获值，或先调用一个接收参数的普通函数再在函数内部创建闭包。

Go 1.22 之后还需要写 job := job 吗？

新模块语义下，使用 := 声明的 range 变量按迭代创建时通常已经能被闭包分别捕获；但显式局部副本仍能表达“这里建立任务输入边界”的意图，并兼容需要旧模块语义的代码。若传的是指针，底层对象是否共享仍要单独判断。

把 &jobs[i] 传给每个任务安全吗？

它让每个任务指向不同的切片元素，但不代表修改自动安全。只读访问通常更容易控制；并发写入仍需要同步，且要注意切片扩容或替换底层数组带来的生命周期问题。

为什么任务结束了，主函数还是提前退出？

通常是没有在启动所有任务后调用 Wait，或者把调用 Wait 放到了任务注册之前。先固定参数，再注册任务，最后等待计数归零，是最容易复查的顺序。