所有在for循环中直接用i或v启动goroutine必然导致数据错乱，因Go复用循环变量地址；应传参修复（如go func(i,v int){}(i,v)）或局部重声明，避免闭包捕获导致错乱与内存泄漏。
所有在 for 循环中直接用 i 或 v 启动 goroutine 的写法，必然导致数据错乱——这不是并发调度慢的问题，而是 Go 语言复用循环变量内存地址的确定性行为。
为什么 goroutine 总读到终值
Go 的 for 和 range 不为每次迭代新建变量，而是在同一栈地址反复赋值。所有 go func() { use(i) }() 捕获的都是这个地址，等 goroutine 真正执行时，循环早已结束，i 停在 len(items)，v 停在最后一次迭代的值。
-
go vet会明确报loop variable i captured by func literal，别忽略它 - 哪怕
v是值类型（如string），只要它内部含指针（如[]byte字段），底层数据仍被共享 - 错误示例：
for _, v := range items { go func() { process(v) }() }→ 全部处理最后一个v
传参式修复：最推荐，语义清晰且无逃逸
把当前值作为参数传入闭包，让求值发生在 go 语句执行瞬间，不依赖外部变量生命周期。
- 适用于所有延迟执行场景：
time.AfterFunc、http.HandleFunc、cron.AddFunc - Go 1.22+ 编译器对这种模式做了逃逸优化，
i不会逃逸到堆 - 示例：
go func(idx int, val string) { fmt.Println(messages[idx], val) }(i, v) - 别写成
go func() { ... }(i)—— 这是语法错误，函数字面量不能带调用括号
局部变量重声明：简单场景够用，但要注意指针陷阱
在循环体内用 := 创建同名新变量，实现变量遮蔽（shadowing），切断与外层变量的地址绑定。
立即学习“go语言免费学习笔记（深入）”；
- 示例：
for i, v := range items { i, v := i, v; go func() { use(i, v) }() } - 注意：对指针/切片/Map 类型，仅
v := v无效 —— 它只复制指针本身，不隔离底层数据 - 若需安全处理
[]byte，应显式传参：go func(data []byte) { ... }(v)，或取元素地址：&items[i] - 别在 defer 中误用：
for _, f := range files { defer os.Remove(f.Name()) }→ 只删最后一个文件
闭包持有大对象引发的内存泄漏风险
闭包隐式延长所有捕获变量的生命周期。若 goroutine 长期运行（如注册为 HTTP handler、存入全局 map、后台 ticker），而它捕获了 *http.Request、几 MB 的 []byte 或 context.Context，这些内存就无法被 GC 回收。
- 验证方法：
go tool pprof -http=:8080 ./binary查 heap，找那些生命周期异常长、且持有大对象引用的 goroutine stack - 缓解策略：只传关键字段（如
req.URL.Path），而非整个req；避免在time.AfterFunc闭包中捕获上下文 - 定时器务必配对调用
ticker.Stop()；defer清理逻辑尽量不用闭包，改用普通函数加显式参数
最容易被忽略的点，不是“怎么修”，而是“什么时候必须修”——只要闭包被传给 goroutine、存入全局结构、或返回给调用方，被捕获的变量就已逃逸；而一旦涉及指针或复合类型，错乱和泄漏往往同时发生。
