Go中for循环启动goroutine时变量被意外共享：因循环变量复用，所有goroutine捕获同一地址，读到最终值；正确做法是传参或创建新变量。
for循环中启动goroutine时变量被意外共享
Go里最典型的并发陷阱：在for循环中用go func() {}()启动多个goroutine，但所有goroutine都读到了循环变量的最终值。这是因为循环变量i或v在整个循环中是复用的，goroutine实际捕获的是变量地址，而非某次迭代的快照。
常见错误写法：
for i := 0; i < 3; i++ {
go func() {
fmt.Println(i) // 总是输出 3, 3, 3
}()
}
解决方式只有两种可靠路径：
- 把循环变量显式传入闭包：
go func(val int) { fmt.Println(val) }(i) - 在循环体内定义新变量并赋值：
val := i; go func() { fmt.Println(val) }()
不要依赖编译器优化或“运气”——Go 1.22 之前所有版本都存在该行为，且它是语言规范所保证的语义。
立即学习“go语言免费学习笔记（深入）”；
range遍历切片/Map时v的复用问题
用range遍历[]string或map[string]int时，循环变量v同样被复用。若将&v或v本身传给goroutine或存入切片，结果不可预测。
典型翻车场景：
data := []string{"a", "b", "c"}
var fns []func()
for _, v := range data {
fns = append(fns, func() { fmt.Print(v) }) // 全部打印 "c"
}
根本原因：每次range迭代都重写v内存位置，闭包捕获的是同一地址。修复必须切断复用链：
- 传参式闭包：
func(val string) { fmt.Print(val) }(v) - 局部拷贝：
val := v; fns = append(fns, func() { fmt.Print(val) }) - 用索引访问原集合：
func() { fmt.Print(data[i]) }（仅适用于切片）
对map尤其要小心——range map顺序不保证，v复用+无序=更难调试。
sync.WaitGroup误用导致提前退出或panic
配合for循环启goroutine时，WaitGroup.Add()调用时机错位是高频崩溃源。常见错误有：
- 在goroutine内部调用
wg.Add(1)→ 竞态，Wait()可能已返回 -
wg.Add()放在循环外、值写死 → 新增迭代项后漏计数 - 忘记
defer wg.Done()或调用多次 → 死锁或panic “negative WaitGroup counter”
正确模式只有一种：
wg := &sync.WaitGroup{}
for _, v := range data {
wg.Add(1)
go func(val string) {
defer wg.Done()
process(val)
}(v)
}
wg.Wait()
注意：wg.Add(1)必须在go前，且参数必须传值（避免v复用）。不要试图在goroutine里补Add——那是竞态温床。
time.Sleep无法替代同步原语
新手常以time.Sleep“等 goroutine 跑完”，这在测试或演示中看似有效，但生产环境必然失效：
- CPU调度不可控，Sleep时间过短则主协程提前退出；过长则拖慢吞吐
- 不同机器、负载下表现不一致，CI/CD 中极易偶发失败
- 掩盖真实同步需求，后续加逻辑后立刻崩塌
真正该用的只有三类：
-
sync.WaitGroup：等待一组任务完成 -
channel（带缓冲或close通知）：传递结果或信号 -
sync.Once、sync.Mutex等：保护共享状态
哪怕只是“等一个goroutine”，也应走done := make(chan struct{}); go func(){ ... close(done) }(); ，而不是<code>time.Sleep(10 * time.Millisecond)。
闭包和并发的交织点很薄，错一毫就全盘偏移。变量生命周期、内存复用、计数时序——这些不是“高级技巧”，而是写对第一行go就必须厘清的底层契约。
