在 go 中，对切片元素（如 `&s[0]`）取地址得到的指针，**仅在切片底层数组未发生扩容时才保持有效**；一旦 `append` 触发底层数组重分配，原指针将悬空并继续指向旧内存，导致读写不一致。
go 的切片（[]T）本质上是一个三元结构：指向底层数组的指针、当前长度（len）和容量（cap）。当你执行 p := &a[0]，p 实际保存的是底层数组首个元素的当前物理地址。该地址是否持续有效，完全取决于后续操作是否导致底层数组被替换。
关键行为来自 append：
- 若 len
- 若 len == cap，append 会分配新底层数组，复制原有数据，并将新元素追加其后——此时 a 指向新内存，而 p 仍指向已被弃用的旧地址。
以下代码清晰展示了这一机制：
package main import "fmt" func main() { c := []int{0} // len=1, cap=1（由字面量初始化） p2 := &c[0] fmt.printf("before append: c[0]=%d, *p2=%d, &c[0]=%pn", c[0], *p2, &c[0]) c = append(c, 1) // len==cap → 触发扩容！新底层数组分配 c[0] = 2 // 修改新数组的首元素 fmt.Printf("after append: c[0]=%d, *p2=%d, &c[0]=%pn", c[0], *p2, &c[0]) // 输出示例：c[0]=2, *p2=0（旧值），&c[0] 地址已变 }值得注意的是，切片初始容量并非绝对固定。例如 var c []int; c = append(c, 0) 在不同 Go 版本或运行环境（如 Go Tour 的沙箱 vs 本地 go run）中，可能分配 cap=1 或 cap=2。这正是你观察到行为差异的根本原因：Go 标准库对小切片扩容的策略（如倍增、预设最小容量）属于实现细节，不保证跨版本/平台一致。
✅ 正确实践建议：
- 避免长期持有切片元素的指针，尤其在可能调用 append 的场景；
- 如需稳定内存布局，显式使用 make([]int, n, m) 预分配足够容量；
- 若必须共享数据，优先通过切片本身（而非指针）传递，或改用 *[]T（指向切片头的指针，但极少必要）；
- 调试时可用 fmt.Printf(“cap=%d, len=%d”, cap(c), len(c)) 辅助判断是否发生扩容。
总结：Go 中“指针到切片元素”不是引用语义，而是快照式内存地址绑定。它的有效性完全依赖底层数组稳定性——而 append 的自动扩容机制恰恰打破了这种稳定性。理解 len/cap 与 append 的交互逻辑，是写出健壮 Go 内存安全代码的关键前提。