slice中存指针易引发数据竞争，因循环变量地址复用（如&i）导致所有指针指向同一内存；正确做法是取可寻址变量元素地址（如&data[i]），并确保其生命周期足够长。
为什么 slice 中存指针容易引发数据竞争或意外修改
Go 的 slice 本身是引用类型，但它的底层数组元素仍是值语义。当你声明 []*int，每个元素是独立的指针变量；而 []int 的每个元素是独立的整数值。常见误操作是：在循环中取 &arr[i] 存入切片，但 i 是循环变量，地址复用导致所有指针最终指向同一个内存位置。
- 错误写法：
var ptrs []*int for i := range arr { ptrs = append(ptrs, &i) // 所有指针都指向同一个 i 的地址！ } - 正确做法：必须取每个元素的地址，且确保该元素生命周期足够长（不能是临时变量）
- 若原数组是局部变量，需确认它不会在函数返回后被回收；更安全的是用已分配的切片或结构体字段
如何安全地构建指向 slice 元素的指针切片
目标是让 ptrs[i] 真实指向 data[i] 的地址。关键在于避免取循环变量地址，改用索引访问原切片元素并取其地址。
- 原切片必须可寻址：不能是字面量直接构造的临时切片（如
[]int{1,2,3}），因为其底层数组可能不可取地址；建议先声明变量再赋值 - 使用
&data[i]而非&i，且data必须是变量（非表达式结果） - 示例：
data := []int{10, 20, 30} var ptrs []*int for i := range data { ptrs = append(ptrs, &data[i]) // ✅ 安全：每个指针指向 data 对应位置 } // 修改 ptrs[0] 会真实改变 data[0] *ptrs[0] = 99 fmt.Println(data) // [99 20 30]
用指针切片实现“引用式”批量更新时的性能与风险权衡
用 []*T 替代 []T 可避免复制大结构体，但带来额外间接寻址开销和 GC 压力。更重要的是：它绕过了 Go 的值拷贝保护机制，任何通过指针的修改都会影响原始数据源。
- 适合场景：需频繁读写底层数据、且明确知道所有指针持有者协同控制生命周期（如 ORM 实体缓存、配置热更新）
- 不适合场景：传参给不信任的函数、跨 goroutine 无同步共享、或原始数据是只读逻辑的一部分
- 注意：
append可能触发底层数组扩容，但指针切片自身扩容不影响已存指针的指向 —— 它们仍指向原data元素，这点和普通切片一致
struct 字段切片中嵌套指针元素的典型误用
当结构体字段是 []*Item，且你通过 itemPtr := &s.Items[i] 获取指针时，得到的是 *[]*Item（即切片头的地址），不是 *Item。这是常见混淆点。
立即学习“go语言免费学习笔记（深入）”；
- 错误：
type Container struct { Items []*Item } c := Container{Items: []*Item{&item1, &item2}} ptrToSlice := &c.Items // 类型是 *[]*Item，不是 **Item - 正确取第 i 个元素指针：
c.Items[i]本身就是*Item，无需再取地址；若要存它的地址（比如想修改该指针本身），才用&c.Items[i]（类型为**Item） - 记住：切片变量名代表“切片头”，
slice[i]才是元素值；对指针切片而言，slice[i]就是你要的指针
&slice[i] 总是安全的，却没确认 slice 本身是否来自可寻址上下文。一旦 slice 是函数返回值且底层数组未逃逸，取地址行为可能在编译期被拒绝，或运行时产生不可预测结果。 
