本文详解 Go 语言中因 for range 循环变量复用导致的 goroutine 指针捕获错误：循环中取地址 &ctx 实际始终指向同一内存位置，造成多个 goroutine 误读最后迭代值。
本文详解 go 语言中因 `for range` 循环变量复用导致的 goroutine 指针捕获错误：循环中取地址 `&ctx` 实际始终指向同一内存位置，造成多个 goroutine 误读最后迭代值。
在 Go 并发编程中，一个高频且隐蔽的陷阱是：在 for range 循环中对循环变量取地址并传递给 goroutine（或存储为指针），结果所有 goroutine 最终访问的是同一个变量的最终值。这并非 Go 的 bug，而是语言规范明确定义的行为——range 循环中的迭代变量 ctx 是单个可重用变量，每次迭代仅对其赋值，而非创建新变量。
以原始代码为例：
for _, ctx := range contexts {
log.Printf("Starting Controller %s.", ctx.Origin)
_ = NewController(&ctx) // ⚠️ 危险！始终取同一个 ctx 变量的地址
}
虽然 contexts 是两个独立的 OriginContext 值，但 ctx 是循环体内唯一的栈变量。第一次迭代时 ctx 被赋值为 {"alpha", ...}，第二次立即被覆盖为 {"bravo", ...}。而 &ctx 始终指向该变量的内存地址。当 NewController 将 &ctx 保存为 originContext *OriginContext 并在 goroutine 中异步使用时，实际读取的已是 ctx 的最终状态（即 "bravo"），导致所有控制器行为一致。
✅ 正确解法一：直接取切片元素地址（推荐）
避免引入中间变量，直接通过索引访问并取地址：
for i := range contexts {
log.Printf("Starting Controller %s.", contexts[i].Origin)
_ = NewController(&contexts[i]) // ✅ 安全：每个 &contexts[i] 指向不同元素
}
此方案零额外内存分配，语义清晰，且符合 Go 的惯用实践。切片元素在内存中连续且独立，&contexts[i] 确保每个控制器持有唯一配置的指针。
✅ 正确解法二：循环内显式声明新变量（明确意图）
若需保留 range 语法的简洁性，可在循环体内用短变量声明“复制”当前值：
for _, ctx := range contexts {
ctx := ctx // ? 关键：创建新的同名局部变量，值拷贝
log.Printf("Starting Controller %s.", ctx.Origin)
_ = NewController(&ctx) // ✅ 安全：&ctx 指向本次迭代的新变量
}
此写法利用了 Go 的变量遮蔽（shadowing）机制：ctx := ctx 在每次迭代中声明一个全新局部变量，其生命周期独立于循环变量 ctx，因此取其地址是安全的。注意：这会为每次迭代分配一次栈空间（微小开销，通常可忽略）。
⚠️ 注意事项与最佳实践
- 永远不要对 for range 迭代变量取地址并跨 goroutine 使用，除非你明确理解其复用语义。
- 若需在 goroutine 中使用循环变量的值，优先选择值传递（如 ctx 本身是小结构体）或显式拷贝（如 ctx := ctx）。
- 对于大对象或需共享修改的场景，确保指针指向的是稳定内存（如切片元素、堆分配对象或全局变量），而非临时循环变量。
- 使用 go vet 工具可检测部分此类问题（如 loop variable captured by func literal），但无法覆盖所有情况，需开发者主动规避。
总结
Go 的 for range 循环变量复用是性能优化设计，但与并发结合时易引发逻辑错误。根本原因在于混淆了“值”与“地址”的生命周期：循环变量的地址是固定的，而其值是动态覆盖的。解决方案的核心原则是——确保指针所指向的内存位置在 goroutine 执行期间保持稳定且唯一。选择索引取址或显式拷贝，即可彻底规避这一经典陷阱。
