Go 的 range 变量为什么会被闭包捕获：修复异步任务参数串值

批量处理订单、文件或消息时，最容易被忽略的一类并发 bug 是：循环看起来把每个元素都交给了 goroutine，日志却连续打印出同一个值。根因通常不是调度器“乱了”，而是闭包捕获了仍在变化的 range 变量。

把循环元素作为参数传进 go func(item string)，让每个 goroutine 拿到自己的值；不要在异步闭包里直接读取会继续变化的 item。

先复现：range 与 go func 为什么会撞在一起

下面的例子模拟把三个文件名交给异步 worker。go func 没有参数，它会从外层读取 item；而循环不会等 goroutine 执行完，item 可能已经进入下一轮。

package main

import (
    "fmt"
    "sync"
)

func main() {
    jobs := []string{"a.csv", "b.csv", "c.csv"}
    var wg sync.WaitGroup
    for _, item := range jobs {
        wg.Add(1)
        go func() {
            defer wg.Done()
            fmt.Println(item)
        }()
    }
    wg.Wait()
}

这里有两条时间线：range 很快把 item 推进到末尾，go func 的函数体却可能稍后才开始。输出顺序本来就不保证，但如果多个任务打印成同一个文件名，问题在于它们读的是同一个外层变量，而不是各自拥有一份输入。

修复路径：把 item 变成闭包参数

将匿名函数改成接收 item string，并在启动时传入当前值。此时 go func(item string) 的参数属于这次调用，后续循环如何推进 range 都不会改写它。

for _, item := range jobs {
    wg.Add(1)
    go func(item string) {
        defer wg.Done()
        fmt.Println(item)
    }(item)
}

也可以在循环体内先创建一个局部副本，但显式参数更容易在代码审查中看出数据边界。需要注意的是，参数隔离只解决值捕获；共享 map、切片底层数组或结果收集器仍然需要自己的同步策略。

验收不能只看一次输出

并发输出顺序不稳定，所以不要把“恰好按 a、b、c 打印”当成通过条件。更可靠的做法是把结果写入带锁的 map，等待 WaitGroup 完成，再检查输入集合与结果集合是否一一对应。

results := make(map[string]bool)
var mu sync.Mutex
// goroutine 内：
mu.Lock()
results[item] = true
mu.Unlock()
// wg.Wait() 后检查 len(results) == len(jobs)

如果业务要求结果按输入顺序返回，就在任务里记录原始下标，最后由主 goroutine 排序；不要靠 goroutine 的完成先后“碰运气”。

常见问题

Go 的 range 变量一定会导致闭包 bug 吗？

不一定。闭包在循环内同步执行，或显式把值传为参数时，就没有这个捕获边界问题；真正危险的是延后执行又直接读取外层变量。

为什么修复后输出顺序还是变化？

参数传值只保证每个任务拿到正确输入，不保证调度顺序。需要有序结果时，记录下标并在汇总阶段排序。

WaitGroup 能替代互斥锁吗？

不能。WaitGroup 只负责等待任务结束，多个 goroutine 同时写 map 仍需互斥锁或改用专门的并发数据结构。

小结

排查这类问题时，先分开看“循环何时改变变量”和“闭包何时读取变量”。让 go func(item string) 接收当前元素，再用等待与集合核对验证完整性，通常比给 goroutine 加延时更可靠。