我在 for range 循环里起了一批 goroutine 并发处理任务,结果它们全都处理了同一个、也就是最后一个任务:一次 Go 循环变量被复用、闭包捕获到的全是最后一个值的深度复盘

那个 bug 是数据"处理结果全错了、还少了一大半"才暴露的:我要并发处理一批任务,代码写得很自然——for range 遍历任务列表,每个任务起一个 goroutine 去处理。本地跑完,结果却诡异得很:明明有 10 个不同的任务,可日志里10 个 goroutine 处理的全是同一个任务(而且是列表里的最后一个);前 9 个任务一个都没被处理。我盯着那段 for _, task := range tasks { go func() { process(task) }() } 看了半天,逻辑明明很清楚啊——每次循环 task 不都是当前这个任务吗?直到我把 Go 的循环机制查清,才看明白,后背发凉:在 Go 1.22 之前,for range 的循环变量(这里的 task)是整个循环复用的同一个变量,而不是每次迭代都新建一个。每轮迭代只是把新值"赋"给这同一个变量。而我的 goroutine 里的闭包,捕获的是这个变量本身(它的引用),而不是某一轮的值;goroutine 是异步的,它们真正开始执行时,for 循环往往早已飞快地跑完了——此时那个被复用的 task 变量,早就停在了最后一个任务上;于是所有 goroutine 读到的 task,都是同一个、停在最后的值。问题的根,是我以为"每轮循环的 task 是各自独立的",但在 Go 1.22 前,它是被复用的同一个变量;闭包捕获了变量、而非当轮的值,异步执行时就全读到了最后一个值。这篇就把这次"循环变量被复用、闭包捕获到最后一个值"的坑,从头到尾复盘一遍。

故障现场:10 个 goroutine 全处理了最后一个任务

问题在于循环里的 goroutine 闭包捕获了"被复用的循环变量",而非每轮的值:

// ✗ 出问题的代码(Go 1.22 之前): 循环里起goroutine引用循环变量
func processAll(tasks []Task) {
    var wg sync.WaitGroup
    for _, task := range tasks {       // ✗ task是【整个循环复用的同一个变量】(Go<1.22)
        wg.Add(1)
        go func() {                     // 闭包捕获的是 task 这个【变量】, 不是当轮的值
            defer wg.Done()
            process(task)               // ✗ goroutine真正执行时, 循环早跑完了,
            //                             task变量已停在最后一个任务上 → 全处理最后一个!
        }()
    }
    wg.Wait()
}

// 现象: 假设tasks有10个 [t0,t1,...,t9]:
// - 期望: 10个goroutine分别处理 t0,t1,...,t9;
// - 实际: 10个goroutine全都处理了 t9(最后一个)! t0~t8一个都没处理。

// 为什么? (Go 1.22之前的循环变量语义):
// 1. for _, task := range tasks 中, task 是【一个变量, 整个循环复用它】;
//    每轮迭代只是执行 task = tasks[i] (把新值赋给同一个变量), 不是每轮新建task;
// 2. go func(){ ... task ... }() 里的闭包, 捕获的是【task这个变量(的引用)】;
//    所有goroutine的闭包, 捕获的是【同一个task变量】;
// 3. go启动goroutine是异步的, 不会立刻执行; for循环会飞快地跑完所有迭代;
//    等goroutine真正调度执行process(task)时, 循环早结束了, task停在最后一个值(t9);
// 4. → 所有goroutine读同一个task变量, 读到的都是t9 → 全处理t9。

// 同样的坑也出现在: 循环里把循环变量存进闭包切片、defer里引用循环变量等。

// 关键: Go<1.22里for range的循环变量是整个循环复用的同一个变量; 闭包/goroutine捕获的是变量而非当轮的值;
//       异步执行时循环早跑完, 全读到最后一个值——循环里起goroutine引用循环变量, 是经典的Go坑。

第一次定位到"所有 goroutine 共享同一个 task 变量、都读到了最后的值"时,我又懊恼又惊讶:"我一直以为每轮循环的 task 是独立的一份,完全没想到它整个循环是同一个变量、被反复覆盖。"这个坑最隐蔽的地方在于:如果不是异步(比如循环里直接 process(task) 同步调用),它完全正常(每轮同步读 task 时,它正好是当轮的值);只有当你把对循环变量的读取"推迟"了(放进 goroutine、闭包、defer),读取发生在"未来"、而变量已被覆盖,坑才会显现。而且它不报任何错,只是静默地处理错了数据——结果全是最后一个,前面的全丢。下面就来拆解,Go 的循环变量到底怎么回事、该怎么正确写。

第一件事:搞懂"循环变量复用 + 闭包捕获变量"的连环坑

我顺着这次事故,把 Go 的循环变量语义和闭包捕获机制彻底理清了。

为什么循环里的 goroutine 全读到了最后一个值?

【核心: Go<1.22的range循环变量是整个循环复用的同一变量; 闭包捕获"变量"而非"当轮的值"; 异步执行时循环已跑完, 全读到最后值】

1. 第一环: 循环变量被"复用"(Go 1.22 之前的语义)
   - for _, task := range tasks: task 是【声明一次、整个循环共用】的一个变量;
   - 每轮迭代做的是 "task = 下一个元素"(赋值/覆盖), 不是"新建一个task";
   - → 整个循环, 内存里就一个task变量, 它的值被一轮轮覆盖, 最后停在最后一个元素。

2. 第二环: 闭包捕获的是"变量", 不是"值"
   - go func(){ process(task) }() 里, 闭包引用了外部的task;
   - 它捕获的是【task这个变量本身(引用)】, 而非"启动时task的那个值";
   - → 闭包之后读task时, 读的是"task变量【此刻】的值", 不是"创建闭包时的值"。

3. 第三环: goroutine是异步的, 执行被推迟
   - go fn() 只是"安排fn稍后在另一个goroutine里跑", 不阻塞、不立刻执行;
   - for循环会非常快地跑完所有迭代(把goroutine都安排上);
   - 等调度器真正执行那些goroutine时, 循环早结束了 → task已停在最后一个值。

4. 三环相扣 → 灾难:
   - (复用的同一变量) + (闭包捕获变量而非值) + (异步推迟到循环后执行)
   - = 所有goroutine读同一个task变量, 而读取时它都是最后一个值 → 全处理最后一个。
   - 注意: 缺了任一环都不会出事(如同步执行就没事、如传值就没事)。

5. Go 1.22 的修复:
   - Go 1.22起, for循环的循环变量改成【每轮迭代都是一个新变量】(per-iteration);
   - → 在1.22+里, 上面的代码"碰巧"对了(每轮task是新的, 闭包各捕获各的);
   - 但: ①很多项目还在1.22以前; ②理解这个机制仍很重要(别依赖版本"碰巧"); ③显式写清更稳妥。

一句话: Go<1.22的range循环变量是整个循环复用的同一个变量, 闭包/goroutine捕获的是这个变量(非当轮的值),
   异步执行时循环已跑完、变量停在最后值, 故全读到最后一个; 解法是把当轮的值"固定"下来(传参或建局部副本)。

这套认知,是整个坑的根。第一环:循环变量被"复用"(Go 1.22 前)——task 是声明一次、整个循环共用的一个变量,每轮只是"task = 下一个元素"(覆盖),最后停在最后一个元素。第二环:闭包捕获的是"变量"不是"值"——闭包之后读 task 读的是"task 此刻的值",不是创建闭包时的值。第三环:goroutine 是异步的,执行被推迟——for 循环飞快跑完,等 goroutine 真正执行时 task 已停在最后一个值。三环相扣 → 灾难:复用的同一变量+闭包捕获变量而非值+异步推迟到循环后执行=所有 goroutine 读同一个变量、读到的都是最后一个值;缺了任一环都不会出事。Go 1.22 的修复:循环变量改成每轮一个新变量;但很多项目还在 1.22 前,且理解机制仍重要、显式写清更稳妥。一句话:Go<1.22 的 range 循环变量是整个循环复用的同一个变量,闭包/goroutine 捕获的是这个变量(非当轮的值),异步执行时循环已跑完、变量停在最后值,故全读到最后一个;解法是把当轮的值"固定"下来。

第二件事:正解——把当轮的值传给闭包,或建循环内局部副本

搞懂了原理,正解就清晰了:把"当轮的值"固定下来——要么作为参数传给 goroutine 的闭包,要么在循环内建一个局部副本,让每个 goroutine 拿到的是各自独立的值。

// ====== 正解一: 把循环变量作为参数传给闭包(最清晰、推荐) ======
func processAll(tasks []Task) {
    var wg sync.WaitGroup
    for _, task := range tasks {
        wg.Add(1)
        go func(t Task) {           // ★ 把task作为参数t传进去
            defer wg.Done()
            process(t)              // ✓ t是【调用go func时task的值的拷贝】, 每个goroutine各一份
        }(task)                     // ★ 启动时就把当轮的task值传进去(此刻求值, 固定下来)
    }
    wg.Wait()
}
// → 关键: go func(t Task){...}(task) —— (task)在启动goroutine的【那一刻】就把task的值拷贝给了t;
//   每个goroutine的t是独立的、固定的当轮值, 不再共享那个会变的task变量 → 正确处理t0~t9。

// ====== 正解二: 在循环内创建一个局部副本(经典写法) ======
func processAll2(tasks []Task) {
    var wg sync.WaitGroup
    for _, task := range tasks {
        task := task                // ★ 在循环体内重新声明一个【新的、局部的】task, 拷贝当轮的值
        wg.Add(1)
        go func() {
            defer wg.Done()
            process(task)           // ✓ 这里捕获的是循环内每轮新建的局部task, 各自独立
        }()
    }
    wg.Wait()
}
// → task := task 看着奇怪, 但它在【循环体内】新建了一个变量, 每轮一个、各自独立 → 闭包各捕获各的。

// ====== 正解三: Go 1.22+ 直接就对了(但别盲目依赖版本) ======
// Go 1.22起循环变量每轮都是新变量, 所以原来的写法"碰巧"对了:
for _, task := range tasks {
    go func() { process(task) }()   // Go1.22+: 每轮task是新变量, 这样写OK
}
// 但: 确认你的go.mod里 go >= 1.22; 团队/CI都是; 否则别依赖。显式传参(正解一)在所有版本都对、最稳。

// ====== 同类坑: defer 在循环里引用循环变量 ======
for _, f := range files {
    file := openFile(f)
    defer file.Close()    // 注意defer在【函数返回时】才执行, 且defer会立即求值它的参数(file此刻的值);
    //                       这里file每轮是新变量(短声明), 所以OK; 但若引用的是range循环变量需同样小心。
}

// 核心: 循环里起goroutine/闭包引用循环变量, 要把"当轮的值"固定下来——
//   要么 go func(t){...}(task) 传参(启动时拷贝值)、要么循环内 task := task 建局部副本;
//   别让闭包共享那个会被覆盖的循环变量(Go<1.22); Go1.22+虽修复但显式传参在所有版本都最稳。

修复的核心,是"把当轮的值固定下来,别让闭包共享会变的循环变量"。正解一:作为参数传给闭包(推荐)——go func(t Task){...}(task),(task) 在启动 goroutine 的那一刻就把当轮的值拷贝给 t,每个 goroutine 的 t 独立、固定。正解二:循环内建局部副本——task := task 在循环体内新建一个变量,每轮一个、各自独立。正解三:Go 1.22+ 直接就对了(每轮新变量),但要确认 go.mod 版本、别盲目依赖。同类坑:defer 在循环里引用循环变量也要小心(defer 立即求值参数、函数返回才执行)。归根结底:循环里起 goroutine/闭包引用循环变量,要把当轮的值固定下来——传参(启动时拷贝值)或循环内建局部副本;别让闭包共享那个会被覆盖的循环变量;Go1.22+ 虽修复但显式传参在所有版本都最稳。

第三件事:Go 并发与闭包里其他常见的坑

排查后我把 Go 并发、闭包相关的其他常见坑也系统梳理了一遍。

Go 并发与闭包的其他常见坑

# 1. 循环变量被闭包/goroutine捕获(本文): 全读最后值。→ 传参或局部副本(Go<1.22)。

# 2. WaitGroup的Add放错位置: 在goroutine内部Add, 可能Wait时还没Add → 提前返回。→ Add在go之前。

# 3. 闭包里defer wg.Done()忘了: goroutine没Done, Wait永久阻塞。→ 每个goroutine确保Done。

# 4. 并发读写map不加锁: panic: concurrent map writes。→ 加锁或用sync.Map。

# 5. goroutine泄漏: 启动的goroutine因channel无人收/无退出条件, 永远不结束。→ 用context控制退出。

# 6. 向已关闭的channel发送: panic: send on closed channel。→ 明确channel关闭的所有权。

# 7. nil channel的收发: 永久阻塞(不是报错)。→ 留意channel是否已make。

# 8. 用共享变量计数不加锁/不用atomic: 数据竞争, 结果不对。→ sync/atomic或加锁。

# 共同根源: Go把并发(goroutine)做得很轻量易用, 但"轻松启动一个并发执行"的背后,
#   隐藏着"共享数据的竞争、执行时机的不确定、变量捕获的时刻"等一系列要小心处理的问题;
#   并发的"易用"降低了启动门槛, 却没降低"正确"的门槛。

# 核心: 写Go并发, 时刻警惕"goroutine异步执行(时机不确定)"和"共享数据(竞争)"两件事;
#   循环变量传值固定、Add在go之前、Done别漏、共享数据加锁/atomic、goroutine要有退出路径; 并发易启动但要写对。

排查让我把 Go 并发与闭包的其他坑也梳理清了。一、循环变量被闭包捕获(本文)。二、WaitGroup 的 Add 放错位置(Add 在 go 之前)。三、闭包里 defer wg.Done() 忘了。四、并发读写 map 不加锁(panic)。五、goroutine 泄漏(用 context 控制退出)。六、向已关闭的 channel 发送(panic)。七、nil channel 收发永久阻塞。八、共享变量计数不加锁/atomic。它们的共同根源是:Go 把并发做得很轻量易用,但"轻松启动一个并发执行"的背后,隐藏着"共享数据的竞争、执行时机的不确定、变量捕获的时刻"等一系列要小心处理的问题;并发的"易用"降低了启动门槛,却没降低"正确"的门槛。核心是:写 Go 并发,时刻警惕"goroutine 异步执行(时机不确定)"和"共享数据(竞争)"两件事;循环变量传值固定、Add 在 go 之前、Done 别漏、共享数据加锁/atomic、goroutine 要有退出路径。下面这张图,是这次循环变量坑的成因与解法:

第四件事:闭包捕获"变量" vs 传参拷贝"值"对比表

这次踩坑后,我把"闭包捕获变量"和"传参拷贝值"的关键区别对比成一张表。

这张表把两种方式钉清了。核心是:区别在于"固定值的时刻"——闭包捕获变量,是把"读取那个值"推迟到了"未来(goroutine 执行时)",而那时变量早被覆盖了;传参拷贝,是在"当下(启动 goroutine 时)"就把值固定了下来;一个读的是"变量将来的样子",一个读的是"值当下的快照"。它给我的最大启发是:当你要"把一个值带到未来去用"(异步、回调、延迟执行)时,是"带走值的快照"还是"带走指向值的引用",是一个生死攸关的区别——带引用,你将来读到的是"它届时的样子"(可能已变);带快照,你读到的是"当时的样子"(固定);而"当时"和"届时"之间,值很可能已经被改得面目全非。这给了我一种处理异步/延迟逻辑的清醒:每当我把一段逻辑"推迟到未来执行"(goroutine、setTimeout、回调、defer)、且它引用了一个'会变的'外部变量时,都要停下来问:"它执行时, 这个变量还是我现在期望的值吗?还是已经被改了?"——如果会被改, 就要把"当下的值"用传参/拷贝固定下来, 而不是引用那个会变的变量;"把要带到未来的值, 在当下就拍下快照固定住",是写对一切异步/延迟逻辑的一个核心技巧。认清固定值的时刻是关键、把带到未来的值在当下拍快照固定——是这个坑带给我的认知。

第五件事:这次事故暴露的"并发易用 ≠ 并发易写对"

这次让我反思更深一层:Go 的 go 关键字让启动并发太轻松了,轻松到我忽略了它背后的复杂性。我把"启动并发"和"写对并发"的难度差对比成表。

这张表道出了并发的真相。核心是:Go 用一个 go 关键字,把"启动一个并发执行"变得极其容易——容易到让人忘记了"并发正确"本身是一件很难的事;"启动并发"的门槛被降到了最低,但"并发执行的时机不确定、共享数据会竞争、变量捕获有时刻"这些本质的复杂性一点没少。它给我的深刻启发是:一个工具/抽象把某件事"变得很容易做",不代表那件事"本质上变简单了"——它降低的往往只是"使用的门槛",而非"正确使用、用好的门槛";而"易用"和"难精"的落差,恰恰是最容易踩坑的地方——因为低门槛诱使你轻率地用,而隐藏的复杂性又在暗处等着你。这给了我一种使用"强大而易用"的工具时的审慎:越是"用起来很简单"的强大特性(go 并发、ORM、自动内存管理、各种"一行搞定"的封装),越要主动去了解它"简单的表象下, 隐藏了什么复杂性和陷阱"——不要被"易用"麻痹, 以为"容易写"就等于"容易写对";"对易用工具背后的复杂性保持敬畏、知其然更知其所以然",是用好强大工具、而不被它反噬的关键。认清并发易用不等于易写对、对易用工具背后的复杂性保持敬畏——是这个 goroutine 坑带给我的工程态度。

第六件事:循环里起 goroutine/闭包时,我现在的自检习惯

现在每当我在循环里要起 goroutine 或创建闭包,我都会先按这张图问自己:

这张图的精髓,是"循环变量被异步闭包引用,就必须把当轮值固定下来"。没引用循环变量安全、同步执行碰巧没事、异步/延迟引用必须传参或建局部副本。这套习惯,让我从"循环里随手 go func(){用循环变量}"变成了"先看有没有异步引用循环变量、有就固定值"——核心始终是:循环里起 goroutine/闭包引用循环变量,务必把当轮的值传参或建局部副本固定下来,别让闭包共享那个会被覆盖的循环变量。

我立下的几条规矩

这场"所有 goroutine 都处理了最后一个任务"的事故,换来了我写 Go 并发时,刻进骨子里的几条铁律:

1. Go<1.22 的 range 循环变量是整个循环复用的同一个变量。每轮覆盖,不是新建。
2. 闭包捕获的是"变量"而非"当轮的值"。异步执行时读到的是变量届时的值。
3. 循环里起 goroutine 引用循环变量,把当轮值传参固定:go func(t){...}(task)。
4. 或在循环内建局部副本:task := task。每轮一个独立变量。
5. Go 1.22+ 修复了循环变量,但别盲目依赖版本。显式传参在所有版本都对。
6. 把要带到未来(异步)用的值,在当下就拍快照固定。别引用会变的变量。
7. 并发易启动不等于易写对。警惕异步时机与共享数据,知其所以然。

写在最后

回头看,这场由"循环里起 goroutine 引用循环变量"引发的、所有任务都被处理成最后一个的事故,真正教给我的,远不止"把循环变量传参"这一个技巧。它让我对"'现在写下的代码'和'它将来真正执行'之间, 隔着一段'时间差'; 在这段时间差里, 世界(变量的值)可能已经变了",有了一次刻骨的体会。我栽跟头,是因为我用"同步、顺序执行"的直觉,去想象"异步、推迟执行"的代码——我看着 for ... { go func(){ process(task) }() },脑子里默认"每次循环, 那个 goroutine 就带着当时的 task 跑起来了";可实际上,goroutine 只是被"安排"了, 真正执行是在"未来某个时刻";而到了那个未来,for 循环这个"世界"早已天翻地覆——task 变量早被覆盖到了最后一个值;我把"写下代码的时刻"和"代码执行的时刻"当成了同一个,而它们之间,隔着一道我没看见的时间裂缝。这让我领悟到一个关于"时序与状态"的深刻认知:在异步/并发/延迟执行的世界里,"代码书写的顺序"不等于"代码执行的顺序/时刻"——你"写在循环里"的东西,可能"执行在循环后";你"引用的变量",到执行时可能"早已不是当初的值";"必须把'书写时序'和'执行时序'在脑子里分开, 去想象'这段代码真正跑起来的那一刻, 周围的状态是什么样'"。这给了我一种面对异步代码时的根本审慎:写任何"会推迟执行"的代码(goroutine、回调、定时器、Promise、defer)时,要刻意地"把自己代入到'它真正执行的那一刻'",去问:"那一刻, 我引用的这些变量/状态, 还是我现在以为的样子吗?"——如果不是, 就把需要的值在"当下"固定/快照下来, 带着它去未来;"带着'执行时刻'的视角去审视延迟代码、而非用'书写时刻'的直觉",是驾驭异步与并发、避免时序陷阱的核心思维。认清书写时序不等于执行时序、把带到未来的值在当下固定下来——这,是我用一次循环变量的事故,换来的、关于 Go 并发、也关于如何在时间差中正确推理代码行为的、最朴素也最深刻的领悟。如果这篇复盘,能让你下次在循环里起 goroutine 引用循环变量时,顺手把它 (task) 传进去固定住,那我对着那满屏"处理了同一个任务"的日志排查的这段时间,就值了。

—— 别看了 · 2026