append 后原切片变量的底层数组指针可能变化：若 len(s) < cap(s)，则复用底层数组；否则分配新数组，原切片底层数组指针不变但新切片指向新地址。
append 后原切片变量的底层数组指针可能变化
Go 中 append 不保证返回新切片与原切片共享同一底层数组。是否变化，取决于当前切片的 cap 是否足够容纳新增元素。若 len(s) ，直接追加，<code>data 指针不变；否则触发扩容，分配新数组，指针必然改变。
常见误判场景：把切片当作“稳定地址容器”，在 append 前取了 &s[0] 或 unsafe.Pointer(&s[0])，之后再 append 并继续用该指针——一旦扩容，指针就指向已释放内存，行为未定义。
扩容规则：2倍增长，但有阈值和对齐约束
Go 运行时的扩容逻辑不是简单翻倍。当原容量 cap 时，新 <code>cap 确实是旧 cap * 2；超过后按约 1.25 倍增长（实际是向上取整到内存页对齐边界）。最终分配的底层数组大小由运行时决定，不完全暴露给用户。
-
make([]int, 0, 1000)→ append 1 个后，cap可能变成 1280 左右，而非 2000 - 扩容后旧数组不会立即回收，但原切片变量（如
s）不再持有对其引用，GC 可能随后回收 - 不同 Go 版本（如 1.21 vs 1.22）对小容量切片的初始分配策略略有差异，但不影响“指针是否变”这一判断逻辑
如何安全判断或避免指针失效
没有运行时 API 能直接比较两个切片是否共用底层数组，但可通过地址计算间接验证：
立即学习“go语言免费学习笔记（深入）”；
func sameBackingArray[T any](a, b []T) bool {
if len(a) == 0 || len(b) == 0 {
return false
}
return &a[0] == &b[0]
}更实用的做法是：如果需要稳定内存地址（如传递给 C 函数、零拷贝序列化），应提前预估最大容量并用 make 分配足额空间，避免后续 append 触发扩容；或者每次 append 后重新获取 &s[0]，绝不缓存旧地址。
注意：nil 切片 append 的特殊行为
nil 切片（var s []int）的 len 和 cap 都为 0，任何 append 都会触发首次分配，此时返回切片的底层数组指针一定与之前无关（因为之前没有底层数组）。这点常被忽略，尤其在初始化逻辑分散时。
容易踩的坑：在函数内接收 nil 切片参数，append 后返回，调用方误以为仍可沿用传入前的某个指针——实际上从第一次 append 就已换内存。
