for-range中&v总指向同一地址是因迭代变量v被复用；正确做法是循环内声明新变量val := v再取&val，或用索引&slice[i]。
for-range 循环里取 &v 总是得到最后一个元素的地址
这是 Go 中最经典的闭包陷阱之一：每次迭代复用同一个变量 v 的内存地址，&v 指向的始终是同一块栈空间。循环结束后，所有指针都指向最终值。
常见错误现象：
把 &v 保存到切片或传给 goroutine，结果所有元素都“变成”了最后一个。
- 正确做法：在循环体内显式创建新变量绑定当前值，再取其地址
- 错误写法：
ptrs = append(ptrs, &v) - 正确写法：
val := v; ptrs = append(ptrs, &val)
示例：
values := []int{1, 2, 3}
var ptrs []*int
for _, v := range values {
val := v // 关键：引入新变量
ptrs = append(ptrs, &val)
}
// ptrs 现在指向三个独立的 int 值
goroutine + for-range 中的 v 捕获问题
和上一条本质相同，但后果更隐蔽：goroutine 异步执行，等它真正读 v 时，循环早已结束，v 已被覆盖。
立即学习“go语言免费学习笔记（深入）”；
使用场景：批量启动 goroutine 处理每个元素，比如发 HTTP 请求、写文件。
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 错误：直接在 goroutine 里用
v—— 所有 goroutine 共享一个v - 正确：用函数参数传值，或在循环内定义新变量并传入
- 推荐写法：
go func(val int) { ... }(v)，避免闭包捕获
注意：不要用 go func() { ... }() 包一层就以为安全，只要里面还直接读 v，问题照旧。
range 切片 vs range map：迭代变量复用行为一致，但 map 迭代顺序不确定加剧了问题暴露概率
无论 range 切片还是 map，Go 都复用迭代变量 v。区别在于：切片按序遍历，你可能“碰巧”没发现 bug；map 迭代顺序随机，每次运行结果可能不同，更容易触发并发或逻辑错乱。
- 切片中
v复用 → 地址共享 → 指针全指向同一位置 - map 中
v同样复用 → 但因顺序不可控，bug 更难复现和调试 - 别依赖 map range 的“看起来正常”的输出，它只是偶然
示例（危险）：for k, v := range myMap { go process(k, &v) } —— &v 始终指向同一个地址，且 v 值随时被下轮覆盖。
为什么不用 for i := range + &slice[i]？
这是最稳妥的替代方案：索引访问天然隔离每个元素的地址，不依赖迭代变量生命周期。
- 适用前提：操作的是切片（
[]T），且需要元素指针 - 优势：无额外变量开销，语义清晰，完全规避
v复用问题 - 注意：如果切片后续被扩容（如 append 导致底层数组重分配），已有指针仍有效（因为指向原数组），但不再反映 slice 当前内容
- map 不支持这种写法，必须走值拷贝或结构体封装
示例：for i := range values { ptrs = append(ptrs, &values[i]) } —— 安全、直观、无需中间变量。
真正容易被忽略的是：这个陷阱不只出现在显式取地址时。只要你在循环中把 v 交给任何异步逻辑、闭包、或长期持有的数据结构，它就可能出问题。Go 不会报错，也不会警告，它只是安静地复用那个变量。
