在 go 中，对切片元素（如 `&s[0]`）取地址得到的是该元素在底层数组中的内存地址；但一旦切片因 `append` 触发扩容，底层数组可能被替换，原指针将指向已失效的旧内存，导致读取陈旧值或未定义行为。

Go 的切片（[]T）本质上是一个三元结构：指向底层数组的指针、长度（len）和容量（cap）。当你执行 p := &a[0]，p 保存的是当前 a 底层数组首元素的地址——这确实是“引用”，而非拷贝。但关键在于：这个引用的有效性完全依赖于底层数组是否发生变更。

而 append 正是破坏稳定性的核心操作。其行为分两种情况：

• ✅ 不扩容：若 len(s)
• ⚠️ 扩容：若 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 代码的关键基础。