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。这是常见混淆点。

• 错误：

  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] 就是你要的指针