这是典型的闭包变量捕获问题：for循环中复用变量i，所有goroutine共享同一地址，导致打印的都是最终值；应显式传参或在循环内创建新变量绑定当前值。
Go 循环中启动 Goroutine 时 i 总是最后一个值
这是最典型的闭包变量捕获问题：在 for 循环里直接用 go func() { fmt.Println(i) }()，所有 Goroutine 打印的都是循环结束后的 i 值（比如 len(slice)），而不是各自预期的索引。
根本原因是：Go 的 for 循环变量 i 是复用的，每次迭代只是修改它的值，而闭包捕获的是变量的地址，不是当前值。所有 Goroutine 共享同一个 &i。
- 最稳妥的做法是把循环变量显式传入 Goroutine：
go func(idx int) { fmt.Println(idx) }(i) - 如果循环体复杂，建议在循环内用新变量接收：
idx := i; go func() { fmt.Println(idx) }()—— 这样每次迭代都创建独立的idx变量 - 别依赖
range的键值解构“自动复制”来绕过问题：for i, v := range s { go func() { _ = i }() }同样出错，i仍是被复用的循环变量
使用 range 遍历时捕获 v（值）也出错？
很多人以为 v 是副本就安全，其实不然。当 v 是指针、接口或结构体字段含指针时，闭包仍可能意外共享底层数据。更隐蔽的问题是：如果 v 是切片或 map，它本身是引用类型，v 变量虽复制，但指向的底层数组/哈希表没变。
- 判断依据看类型：基本类型（
int,string）和非嵌套结构体一般安全；[]byte,map[string]int,*T,interface{}都要小心 - 保险做法统一用传参方式：
go func(val T) { ... }(v)，避免任何隐式共享 - 如果
v很大（比如 megabytes 级切片），传值有开销，此时应传指针 + 显式拷贝关键字段，而非依赖闭包捕获
在 defer 中闭包捕获循环变量会怎样？
defer 和 Goroutine 一样延迟执行，同样受循环变量复用影响。常见于资源清理场景：for _, file := range files { defer os.Remove(file.Name()) } —— 最终可能只删了最后一个文件。
立即学习“go语言免费学习笔记（深入）”；
- 必须立即绑定当前值：
for _, file := range files { f := file; defer func() { os.Remove(f.Name()) }() } - 或者用带参数的匿名函数：
defer func(f *os.File) { os.Remove(f.Name()) }(file) - 注意：
defer在函数返回前才执行，若循环中发生 panic，这些defer仍按后进先出顺序执行，但绑定的变量值已确定
用 sync.WaitGroup 等待多个 Goroutine 时怎么避免变量污染？
很多人把 wg.Add(1) 放在循环外或位置不对，导致计数错误，但这不是闭包问题；真正容易混的是：在闭包里误用外部 wg 或 err 变量，尤其多个 Goroutine 并发写同一个 error 变量。
-
sync.WaitGroup本身是线程安全的，但它的方法调用位置很重要：wg.Add(1)必须在go语句之前，且不能放在闭包里 - 错误收集推荐用带锁的切片或
sync.Once+ 指针，别让多个 Goroutine 直接赋值给同一个err变量 - 一个典型反例：
var err error; for _, v := range data { go func() { if e := do(v); e != nil { err = e } }() }—— 竞态且结果不可预测
闭包陷阱的本质不是语法缺陷，而是对变量生命周期和内存布局的误判。哪怕写了十年 Go，只要没亲手 debug 过一次 for i := 0; i 输出三个 3，就还没真正跨过这道坎。
