append是否改变底层数组地址只取决于len(s)==cap(s)：成立则必扩容、地址大概率变；不成立则复用原数组、地址不变。预设足够cap（make([]t, 0, n)）是确保地址稳定的唯一可靠方式。
append 后切片底层数组地址可能变，也可能不变——关键看是否触发扩容，而扩容与否取决于 len 和 cap 的关系，不是“一定会变”或“一定不变”。
怎么判断 append 是否会改变底层数组地址
只看一个条件：len(s) == cap(s)。成立则必扩容，底层数组地址大概率变；不成立则复用原数组，地址不变。
- 例如
s := make([]int, 3, 5)，此时len=3、cap=5，append(s, 99)不扩容，&s[0]地址不变 - 但
s := make([]int, 5, 5)，再append(s, 99)就必须扩容，&s[0]指向新内存，旧地址失效 - 注意：
fmt.Printf("%p", s)打印的是s.array字段值（即底层数组首地址），不是切片变量自身的栈地址
扩容后旧切片变量为什么“看不到”新元素
因为 append 总是返回新切片；若发生扩容，返回值的 array 字段指向新分配内存，而原变量仍持有旧 array 地址。
- 常见误写：
s := []int{1}; t := s; s = append(s, 2)→ 此时t和s底层数组已分离，t不含2 - 函数传参也一样：形参
s在函数内append后若扩容，返回值未赋回给调用方变量，则外部无感知 - 验证方式：用
unsafe.Pointer(&s[0])对比扩容前后，比fmt.Printf("%p", s)更直接
Go 1.22 中实际扩容策略与 cap 增长规律
当前稳定版（Go 1.22）仍沿用平滑扩容逻辑，但不再硬分 1024 边界；核心是「最小够用 + 对齐优化」，实际 cap 增长非简单翻倍。
- 小容量（如
cap=1→2→4→8）常呈倍增，但cap=7追加 1 元素后未必变成 14，可能只到 8（刚好容纳） - 大容量时（如原
cap=1200），追加少量元素可能只涨到 1280 或 1360，取决于运行时对齐要求（如 64 字节对齐） - 用
growslice源码或runtime/debug.ReadGCStats观察真实分配，别依赖理论公式推算
预分配 cap 是最可控的地址稳定手段
如果你需要确保整个生命周期底层数组地址不变（例如传递给 CGO、内存映射场景），唯一可靠方式是初始化时用 make([]T, 0, N) 预设足够 cap。
- 循环中累计
append1000 次？直接s := make([]int, 0, 1000)，避免任何一次扩容 - 不确定最终长度？宁可略高估（如预设 2048），也比频繁 realloc + 地址漂移更可控
- 注意：
make([]T, N)创建的是len==cap==N的切片，第一次append就可能触发扩容，要写成make([]T, 0, N)
真正容易被忽略的点：地址是否变化，和「有没有修改元素」无关，只和「有没有重新分配底层数组」有关；而后者完全由 len/cap 状态和运行时内存策略联合决定，不是纯数学计算能穷举的。
