这是典型的闭包变量捕获问题：for循环中启动goroutine时，所有协程共享同一变量i的地址，待其执行时循环已结束，i值固定为终值（如len(slice)）。
for 循环中启动 goroutine 时 i 总是最后一个值
这是最典型的闭包变量捕获问题：在 for 循环里用 go func() { ... }() 启动协程，所有协程读到的循环变量 i 都是循环结束后的最终值。
根本原因是：goroutine 是异步执行的，而 i 是循环作用域里的同一个变量，地址没变；等 goroutine 真正运行时，for 早已跑完，i 停在了终值（比如 len(slice)）。
常见错误写法：
for i := 0; i < len(items); i++ {
go func() {
fmt.Println(i) // 所有 goroutine 都打印出相同的数，比如 5
}()
}
解决方法只有两个可靠路径：
立即学习“go语言免费学习笔记（深入）”；
- 把
i作为参数传进 goroutine 函数：go func(idx int) { fmt.Println(idx) }(i) - 在循环体内用新变量显式拷贝：
idx := i; go func() { fmt.Println(idx) }()
第一种更推荐——语义清晰、无歧义，且 Go 1.22+ 编译器对这种传参模式做了逃逸优化，性能几乎无损。
range 遍历切片/Map 时 v 被所有 goroutine 共享
range 的迭代变量 v 在整个循环中复用同一块内存地址，和 i 本质一样，但更容易被忽略，尤其在处理结构体或指针时。
错误示例：
for _, v := range items {
go func() {
process(v) // v 指向的始终是最后一次迭代的值
}()
}
如果 v 是结构体，你可能拿到的是“半更新”状态；如果是指针，*v 可能 panic 或读到脏数据。
修复方式和上一条一致，但要注意：传值还是传指针取决于你的意图：
- 想处理每个元素的副本 →
go func(val T) { process(val) }(v) - 想原地修改原切片中的元素 → 必须传索引或原始地址：
go func(idx int) { process(&items[idx]) }(i)
别试图在 goroutine 里直接取 &v，那拿到的是循环变量本身的地址，不是原数据地址。
闭包捕获外部变量引发的内存泄漏风险
闭包会隐式持有它引用的所有外部变量。如果这些变量很大（比如一个几 MB 的 []byte），而 goroutine 又长期不退出，这块内存就一直无法被 GC 回收。
典型场景：
- HTTP handler 里启了一个后台 goroutine，闭包捕获了整个
*http.Request或context.Context - 定时任务中闭包捕获了大 map 或缓存句柄，但 goroutine 没有明确退出机制
检查方法很简单：用 pprof 查看 goroutine stack 和 heap，找那些本该结束却还在运行、且持有大对象引用的闭包。
预防建议：
- 只捕获真正需要的字段，而不是整个 struct 或 context：
id := req.URL.Query().Get("id"); go func(id string) { ... }(id) - 避免在长生命周期 goroutine 中闭包捕获局部大对象，改用参数传递或全局池管理
Go 1.22+ 的 loopvar 模式不是银弹
Go 1.22 引入了 -gcflags="-lang=go1.22" 下的 loopvar 模式，让 range 和 for 的变量默认按每次迭代重新声明（类似 JavaScript 的 let）。但这只影响编译期语义，不改变运行时行为逻辑。
它确实能缓解部分问题，比如下面代码在 1.22+ 默认开启 loopvar 后会按预期输出 0~4：
for i := 0; i < 5; i++ {
go func() { fmt.Print(i) }()
}
但注意几个关键限制：
- 仅对
for和range的**迭代变量**生效，对普通变量（如var x = i）无效 - 不解决内存泄漏问题——变量仍被闭包持有，只是值“看起来对了”
- 跨 package 或 vendored 依赖若用旧版 Go 编译，行为可能不一致，CI 环境要统一语言版本
所以，靠语言特性“自动修复”不如主动写清楚意图。老项目升级后也得逐个验证 goroutine 行为，不能假设没问题。
最稳的写法永远是：显式传参、最小化捕获、及时清理资源。复杂点在于你要判断哪个变量真正在被并发读写，而不是只盯着 i 或 v 看。
