在 go 中，对切片元素（如 `&s[0]`）取地址得到的是该元素在底层数组中的内存地址；但一旦切片因 `append` 触发扩容，底层数组可能被替换，原指针将指向已失效的旧内存，导致读取陈旧值或未定义行为。
Go 的切片（[]T）本质上是一个三元结构：指向底层数组的指针、长度（len）和容量（cap）。当你执行 p := &a[0]，p 保存的是当前 a 底层数组首元素的地址——这确实是“引用”，而非拷贝。但关键在于：这个引用的有效性完全依赖于底层数组是否发生变更。
而 append 正是破坏稳定性的核心操作。其行为分两种情况：
- ✅ 不扩容：若 len(s) < cap(s)，append 直接复用原底层数组，仅更新 len。此时 &s[0] 指针依然有效，*p 与 s[0] 始终同步；
- ⚠️ 扩容：若 len(s) == cap(s)，append 会分配全新底层数组，将原数据复制过去，并返回指向新数组的新切片。此时原指针 p 仍指向旧内存，而 s[0] 已位于新地址——二者彻底脱钩。
以下代码清晰揭示这一机制：
package main
import "fmt"
func main() {
c := []int{0} // len=1, cap=1（注意：make([]int, 1) 也是 cap=1）
p2 := &c[0]
fmt.Printf("before append: c[0]=%d, *p2=%d, &c[0]=%p\n", c[0], *p2, &c[0])
c = append(c, 1) // 触发扩容！cap 从 1→2（典型实现），底层数组被替换
c[0] = 2
fmt.Printf("after append: c[0]=%d, *p2=%d, &c[0]=%p\n", c[0], *p2, &c[0])
// 输出示例：c[0]=2, *p2=0（旧值！）, &c[0] 地址已变
}? 为什么 Go Tour 和本地结果不同？ 因为 append 的扩容策略（尤其是初始容量增长因子）属于实现细节，未在语言规范中强制约定。Go 1.4、Go 1.21 或 Playground 可能采用不同的扩容算法（如 cap*2、cap+1 或基于大小的阶梯式增长）。这意味着 c = append(c, 1) 是否触发扩容，取决于当前 cap(c) —— 而 cap(c) 又由前序 append 的历史行为隐式决定。绝对不可跨版本或跨环境假设其一致性。
✅ 安全实践建议：
- ❌ 避免长期持有对切片元素的指针（尤其是后续会 append 的切片）；
- ✅ 如需稳定地址，改用 make([]T, n, n) 预分配足够 cap，确保 append 不扩容；
- ✅ 或改用固定数组（[N]T）+ 切片视图，规避动态扩容；
- ✅ 在性能敏感场景，用 unsafe.Slice（Go 1.17+）或 reflect.SliceHeader 需极度谨慎，并充分测试。
总之，Go 中的切片指针不是“智能引用”，而是裸内存地址——它的命运与底层数组的生命周期完全绑定。理解 len/cap/append 的交互逻辑，是写出健壮 Go 代码的关键基础。
