go循环变量复用同一内存地址，闭包捕获的是变量引用而非值；所有迭代共享该地址，导致最终均读取终值。
所有在 for 循环里直接引用循环变量的闭包，都会捕获同一个变量地址，而不是你想象中的“每次迭代的值”。这不是 goroutine 延迟执行导致的偶然现象，而是 Go 语言对循环变量复用的确定性行为——无论有没有 go，只要闭包引用了 i 或 v，它拿到的就是那个不断被覆盖的内存位置。
为什么 for i := 0; i 总是输出五个 <code>5
因为 i 在整个循环中只有一份内存地址。每次 i++ 都是在改写同一块内存；所有匿名函数捕获的都是 &i，不是 i 的副本。等 goroutine 真正调度执行时，循环早已结束，i == 5 已成定局。
- 这个行为与是否加
go无关：去掉go写成同步调用，结果仍是五个5 -
go vet能静态检测出这类问题，建议 CI 中强制启用 - Go 1.22+ 对
range的值变量做了部分复制优化，但这是实现细节，不可依赖
修复必须显式切断闭包与循环变量的绑定
只有两种可靠方式，且都要求你在启动闭包前完成变量隔离：
-
传参模式（推荐）：把当前值作为参数传入闭包，例如
go func(idx int) { fmt.Println(idx) }(i)—— 参数传递是值拷贝，语义清晰、无歧义、兼容所有 Go 版本 -
局部变量快照：在循环体内用短变量声明创建新绑定，例如
i := i，再让闭包引用这个新i—— 注意这行必须写在go func()之前，且作用域要能覆盖闭包体 - 不要用
&v试图取“当前值地址”，那取到的仍是循环变量本身的地址，不是原切片元素的
range 遍历结构体或指针时更危险
当 v 是结构体或指针类型时，表面看是“值语义”，但闭包捕获的仍是复用变量的地址。如果 v 是 *Item，所有闭包拿到的都是指向最后一个 Item 的指针；如果 v 是结构体但含 []byte 字段，多个 goroutine 并发修改仍会触发 data race。
- 想处理副本 → 用
go func(val Item) { ... }(v) - 想操作原数据 → 用索引访问原切片：
go func(idx int) { process(&items[idx]) }(i) - 别写
v := &v，那只是把循环变量地址又存了一次，毫无意义
真正容易被忽略的点是：问题不在 goroutine 启动时机，而在你默认“每次循环都有一个新变量”。Go 没有按值捕获语法，所有“捕获当前值”的效果，都得靠你手动触发赋值或参数传递来实现。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
