for range []T 时v是 T，直接用v.Field；写v会触发T值拷贝，导致CPU/内存带宽浪费、GC压力上升；需修改原指针用ptrSlice[i] = &newT，改所指值用v = newT。
![golang中for range一个指针数组[]*t的性能考量_避免解引用开销](https://img.php.cn/upload/article/000/969/633/177157728925626.jpeg)
for range \[\]\*T 时直接用指针，别碰 *v
Go 的 for range 遍历 []*T 时，每次迭代的 v 是 T 类型的**值拷贝**（即解引用后的副本），不是指针。这看似无害，但若 T 是大结构体（比如几百字节以上），频繁拷贝会吃掉明显 CPU 和内存带宽。
常见错误现象：go tool pprof 显示 runtime.memmove 占比异常高；GC 压力上升；明明只读数据，却触发大量临时对象分配。
- 正确做法：直接用
v（它已经是*T），不要写*v或*v.Field - 错误写法示例：
for _, v := range ptrSlice { use(*v) }—— 这里*v强制解引用，触发拷贝 - 如果真要访问字段，写成
v.Field（v是指针，点操作符自动解引用）
range \[\]\*T 和 range \[\]T 的底层循环变量类型完全不同
这是最容易混淆的点：Go 不会因为底层数组存的是指针，就让 v 变成指针；v 的类型完全由切片元素类型决定，但语义上它仍是“被遍历出的值”。
使用场景差异：
立即学习“go语言免费学习笔记（深入）”；
-
for _, v := range []*T{&a, &b}→v类型是*T，值是地址，零拷贝 -
for _, v := range []T{a, b}→v类型是T，值是结构体副本，有拷贝开销
性能影响：后者在每次迭代都调用 runtime.convT2E（如果进 interface{}）或隐式 memmove；前者只是寄存器传地址，几乎无开销。
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
想批量修改 \[\]\*T？别用 range 的 v，改用下标
如果你需要在循环中给每个 *T 所指向的值赋新值（比如重置字段），直接对 v 赋值是无效的——v 是指针副本，改它只改了副本里的地址，不影响原数组中的指针。
错误示例：for _, v := range ptrSlice { v = &newT } —— 这只是把循环变量 v 指向新地址，原 ptrSlice[i] 毫无变化。
- 真正要改原数组中的指针：用
for i := range ptrSlice { ptrSlice[i] = &newT } - 真正要改指针所指的值：用
for _, v := range ptrSlice { *v = newT }（此时解引用不可避免，但只拷贝一次T值，而非每次循环都拷贝） - 注意：
*v = newT的开销取决于T大小，和v是不是指针无关
逃逸分析常被忽略：range 变量 v 是否逃逸，影响堆分配
哪怕你没显式取地址，只要 v（类型 *T）被传入函数、赋给全局变量、或作为 interface{} 值传递，它就可能逃逸到堆上——而 v 本身只是个指针，逃逸成本低；但如果你写了 *v，整个 T 值就可能被抬升为堆对象。
验证方式：go build -gcflags="-m" main.go，留意类似 ... escapes to heap 的提示。
- 安全模式：所有操作基于
v（*T），避免*v出现在函数参数、map value、channel send 等上下文中 - 危险信号：
fmt.Println(*v)、append([]interface{}{}, *v)、someMap[key] = *v
结构体越大，*v 导致的逃逸代价越不可忽视——不是慢一点，是可能让 GC 频率翻倍。
