闭包中for循环变量被复用导致所有goroutine捕获同一地址，最终都输出循环结束时的最终值；正确做法是在循环内用临时变量复制i或使用带索引的参数传递。
闭包里用 for 循环变量会复用同一个地址
Go 的 for 循环变量是复用的，每次迭代不创建新变量，而是更新同一块内存。闭包捕获的是变量的地址，不是值——所以所有 goroutine 最终都看到循环结束时的最终值。
常见错误现象：for i := 0; i 输出全是 <code>3（不是 0 1 2）。
- 根本原因：闭包捕获的是
&i，而i在循环结束后为3 - 解决方式：在循环体内用局部变量显式复制值，比如
for i := 0; i - 也可以传参：
go func(i int) { fmt.Println(i) }(i)—— 这是最清晰、最不容易出错的方式 - 注意：不能只写
i := i就以为“安全”，必须确保它出现在 goroutine 启动前，且作用域覆盖闭包
range 遍历切片/map 时的闭包陷阱和指针风险
range 的索引和值变量行为和普通 for 一样：复用。但值语义更隐蔽——尤其遍历结构体切片时，你以为捕获的是结构体副本，其实闭包拿到的仍是循环变量的地址。
使用场景：启动多个 goroutine 处理 items 列表中的每个元素，比如发 http 请求。
立即学习“go语言免费学习笔记（深入）”；
- 错误写法：
for _, item := range items { go func() { api.Call(item.ID) }() }→ 所有 goroutine 可能用错item.ID - 正确做法一（传参）：
go func(item Item) { api.Call(item.ID) }(item) - 正确做法二（显式复制）：
item := item; go func() { api.Call(item.ID) }() - 如果
item是大结构体，传参会拷贝；若只想传引用，确保你清楚生命周期 —— 不要让 goroutine 访问已超出作用域的栈变量
闭包捕获外部变量 vs 副本传递：Go 没有“按值捕获”语法
Go 的闭包只能捕获外部变量的引用（本质是地址），没有类似 JavaScript 的“值捕获”机制。所谓“副本”，全靠开发者手动触发赋值或函数参数传递来实现。
性能 / 兼容性影响：手动复制变量成本极低（整数、指针就是一次赋值），但若误以为结构体字段被自动隔离，可能引发竞态或逻辑错乱。
-
func() { fmt.Println(x) }捕获的是&x，不是x的副本 - 想获得副本，必须显式写
x := x或作为参数传入闭包 - 如果外部变量是
*T，闭包拿到的是指针副本（指向同一对象），不是对象副本 —— 修改仍会影响原数据 - 并发读写未加锁的共享变量，即使“看起来是副本”，也可能因底层指针共享而触发
data race
调试这类问题的关键信号
当多个 goroutine 行为一致但不符合预期（比如全打印相同 ID、全访问同一 map key、全 panic 在同一行），大概率是闭包捕获了循环变量。
可借助 go run -race 检测部分场景，但 race detector 不一定能抓到纯逻辑错（比如值错但没竞态）。
- 检查所有在 goroutine 内直接使用的循环变量名，确认是否经过传参或显式赋值隔离
- 把闭包内访问的变量打印其地址：
fmt.printf("%p", &i)—— 如果多个 goroutine 打印出同一地址，就是复用问题 - 临时把 goroutine 改成同步调用（去掉
go），看输出是否正常 —— 能快速定位是否为并发+闭包组合问题
闭包捕获的本质是地址复用，不是语言缺陷，而是 Go 显式控制内存模型的一部分。真正容易被忽略的，是那些没报错、没 panic、甚至跑测试也通过，但线上批量处理时 ID 错乱、状态覆盖、请求发到错误端点的 case —— 它们往往就藏在一行没加参数的 go func() { ... }() 里。