Go goroutine 闭包捕获循环变量如何修复

修复 Go goroutine 闭包捕获循环变量，最直接的写法是把当前轮的值放进函数参数：go func(job Job) { ... }(v)，在函数体里只使用 job。不要先认定所有 for range 闭包都有问题：Go 1.22 起，新语义下用 := 声明的迭代变量每轮独立；用 = 给外部已有变量赋值仍会复用那个变量。参数传递能把任务输入写清楚，但不能自动深拷贝指针、切片或 map。

Go 官方地址：https://go.dev/

为什么多个任务会读到同一变量

以批量生成三份订单摘要为例，每个任务本应得到不同的订单号。如果循环把数据不断赋给同一个外部变量，而匿名函数又直接读取它，多个任务就依赖同一存储位置。函数定义在循环里，并不意味着自动保存了定义时的全部值。结果可能重复、错配，也可能因调度不同而表现不一致；不要把“必定全是最后一项”当成语言保证。

// 反例片段：v 在循环外声明，赋值式 range 会复用它。
var v Job
for _, v = range jobs {
    go func() {
        fmt.Println(v.ID) // 异步读取共享 v；循环也在更新它。
    }()
}
// 此片段只说明风险，不提供完整等待逻辑，也不要用于生产。

这个反例的循环边界有 jobs、外部变量 v；闭包边界有匿名函数、任务甲、任务乙。jobs 给 v 提供每轮赋值，匿名函数引用 v，两项任务都运行该匿名函数，因此它们依赖相同的变量。并发读取与更新还可能构成数据竞争。即使延后执行所有闭包而不使用 goroutine，共用变量也仍可能造成身份错配。

闭包问题的历史背景可阅读官方文章：https://go.dev/blog/loopvar-preview。这里使用原创订单场景，不复制其中的例子。

先确认循环使用哪一种语义

Go 1.22 的改变不是“闭包改成按值捕获”，而是符合新规则的循环声明变量每轮独立。模块 go.mod 的 go 指令及可能的文件级构建约束影响语言版本选择，只看本机安装的新编译器版本不够。这个变化已经正式落地，不应继续把预览文章里的未来时态当成现状。

语言规则见 https://go.dev/ref/spec#For_statements，正式变化见 https://go.dev/doc/go1.22。先判断变量在哪里声明，再判断异步函数读的到底是哪个标识符，能避免在已正确的新代码中机械添加遮蔽赋值。

把每轮任务作为参数传入

下面保留外部变量复用形式，以突出修复点：调用 go 函数时把 v 作为实参，在调用方求值；新 goroutine 的函数体只读取自己的 job。示例中的 Job 只含标量与字符串，没有可变引用字段。

package main

import (
    "fmt"
    "sync"
)

type Job struct {
    ID   int
    Name string
}

func main() {
    jobs := []Job{
        {ID: 41, Name: "订单摘要甲"},
        {ID: 72, Name: "订单摘要乙"},
        {ID: 93, Name: "订单摘要丙"},
    }
    var wg sync.WaitGroup
    var v Job
    for _, v = range jobs {
        // 必须在启动 goroutine 之前登记，避免 Wait 先看到零计数。
        wg.Add(1)
        go func(job Job) {
            defer wg.Done() // 无论函数怎样正常返回，都登记任务结束。
            // 只使用形参 job，不再从外部读取正在变化的 v。
            fmt.Printf("任务 %d: %s\n", job.ID, job.Name)
        }(v)
    }
    wg.Wait() // 等全部任务结束，避免 main 提前退出。
}

修复图把任务输入分组为 jobs、实参 v、形参 job，把任务协作分组为任务函数、WaitGroup。jobs 与 v 是取值关系，v 与 job 是参数复制关系，job 是任务函数的输入，任务函数与 WaitGroup 关联完成登记。WaitGroup 解决的是等待，不负责修复变量捕获；真正改变数据身份的是形参 job。

不需要通过 Sleep 来“给任务留时间”。Sleep 不能固定变量身份，也无法保证全部任务完成。sync 的等待契约见 https://pkg.go.dev/sync#WaitGroup。实际业务函数如果返回 error，应额外设计错误收集；go 调用不会把返回值交给主函数。

参数副本不等于深拷贝

假设 Job 后来增加了指针字段、map 配置或切片负载。把整个 Job 传进去，只复制结构体字段；指针仍指向原对象，切片仍可能共享底层数组，map 仍关联同一份数据。如果主循环或其他任务继续修改这些内容，变量身份修复后仍可能存在共享数据竞争。

取舍由数据用途决定：只读且发布后不再修改的数据可以共享；必须由单个任务修改的负载应在交付任务前明确复制其可变部分；本来就是共享状态的对象应采用合适的同步或消息协调。不要把 copy := v 的命名误当成深拷贝承诺，也不要在未了解对象大小与语义时盲目复制所有数据。

同样，参数写成 go func(p *Job) { ... }(&v) 并没有解决外部 v 的共享问题：复制的是地址。对带锁的结构体更不能为了修复闭包而随意按值复制已经使用的锁；应传递稳定的对象指针，并单独处理对象同步。

怎样判断修复是否覆盖真实任务

对三份订单摘要，验收目标应是订单身份与内容一一匹配，每个预期任务恰好被处理一次，主函数等到任务结束。并发输出不承诺按 41、72、93 排列，不能仅因顺序变化认定修复失败。也不要仅凭偶尔打印正确认定捕获问题消失。

可以在自己的项目中编写身份集合测试，对重复、缺失与错误映射做断言，并以 race detector 补充检查实际执行路径中的数据竞争。检测未报错不证明所有路径安全，也不替代业务身份断言。官方介绍：https://go.dev/doc/articles/race_detector。本文代码和两张图为说明材料，没有展示实测日志或声称执行过这些测试。

新版 Go 还需要 v := v 吗？

新语义下声明式循环通常不需要为了旧式捕获问题再遮蔽一次。跨旧版本维护时，显式参数常更便于阅读；关键是形参在函数体中真正被使用。

传了参数，却继续 fmt.Println(v.ID) 怎么办？

这仍在读取外部 v。应改为 job.ID，并检查函数体内所有外部数据引用，不能只改函数签名。

换成 channel 或加 Mutex 就能固定任务值吗？

同步能协调访问，却不自动表达“当前任务应处理哪一项”。先建立独立任务输入，再决定怎样协调共享数据与结果，才不会把身份错误藏在同步代码里。

修复时记住三个独立问题：循环变量是否每轮独立、参数是否包含共享引用、任务是否正确等待结束。它们分别决定任务身份、数据安全和生命周期，不能用一个补丁代替全部判断。