append后原切片变量没变，因为append返回新切片，而切片是含ptr、len、cap的值类型；不赋值接收返回值，变量仍指向旧底层数组。
append 后原切片变量为什么没变
因为 append 返回的是新切片，而切片本身是值类型——它包含三个字段：ptr、len、cap。当你写 s = append(s, x)，你是在给变量 s 重新赋值；如果不赋值，原变量仍指向旧底层数组（可能已满，也可能被扩容后丢弃）。
常见错误现象：
– 写完 append(s, x) 没接返回值，结果打印 s 还是原来长度
– 在函数里对参数切片 append 却不返回，调用方看不到新增元素
- 必须显式接收返回值：
s = append(s, x) - 函数若要修改切片内容并让调用方感知，得返回新切片：
func extend(s []int, x int) []int { return append(s, x) } - 底层数组是否复用，取决于当前
cap是否足够：够则复用原数组，ptr不变；不够则分配新数组，ptr变更
扩容时 ptr 突然变化的判断依据
Go 的切片扩容策略不是固定倍增，而是分段增长：
– 小于 1024 元素时，按 2 倍扩容
– 超过后按 1.25 倍增长（向上取整）
但关键不是倍数，而是「当前 cap 是否够用」。
使用场景：调试内存泄漏、排查指针失效（比如把切片元素地址存进 map，之后又 append 导致底层数组搬迁，地址失效）
立即学习“go语言免费学习笔记（深入）”；
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 检查是否扩容：
oldCap := cap(s); s = append(s, x); if cap(s) != oldCap { /* 扩容发生了 */ } - 扩容后
ptr一定变——因为分配了新数组；未扩容时ptr通常不变（除非用了copy或make显式换底层数组） - 不要依赖「扩容前后 ptr 相同」来判断数据是否迁移；唯一可靠方式是比对
&s[0]地址
避免因 append 导致的悬垂指针
当保存了切片中某个元素的地址（比如 &s[i]），后续任意一次可能触发扩容的 append 都会让该指针失效——如果底层数组被替换，原地址指向的内存可能已被回收或复用。
典型错误场景：
– 把 &s[0] 存进结构体字段，之后反复 append 切片
– goroutine 中读取一个长期存活的元素指针，但主协程在不停追加
- 尽量避免保存切片内元素的指针；改用索引 + 切片本身传参
- 如必须用指针，确保切片不会再扩容：提前
make([]T, n, n)固定 cap，或用cap检查剩余空间 - 调试时可打印地址验证：
fmt.Printf("%p", &s[0])，两次调用间地址变了就说明 ptr 已迁
map 中存切片元素指针的坑
这是最隐蔽也最容易出问题的组合。map 的键值存储不阻止 GC，但一旦切片因 append 扩容导致底层数组重分配，原指针就变成悬垂指针，后续解引用可能 panic 或读到脏数据。
性能影响：看似只是多一次内存分配，但引发的问题是不可预测的——可能是偶发 panic，也可能是静默数据错乱。
- 绝对不要往 map 里存
&s[i]这类切片内元素地址 - 如果需要映射关系，改用索引（
map[key]int存下标），访问时再通过切片取值 - 或者把数据转成独立对象（struct），由 map 持有该对象指针，彻底脱离切片生命周期
真正麻烦的从来不是扩容机制本身，而是人误以为「切片像 slice header 一样轻量，改它不影响已有指针」——其实只要底层数组换掉，所有基于旧 ptr 的地址都废了。
