go切片扩容仅在len==cap时触发内存复制，并非每次append都发生；切片是24字节值类型，含array、len、cap三字段，len未超cap时不复制。
Go 切片扩容时的内存复制不是“每次都发生”，而是只在 len == cap 时触发；理解这一点，比死记扩容倍数更重要。
扩容只发生在容量耗尽时，不是每次 append 都复制
切片本身是 24 字节的值类型结构体（64 位系统），含 array、len、cap 三个字段。只要 len ，<code>append 就直接往底层数组末尾写，不分配新内存，也不复制数据。
- 错误认知：以为
append必然导致复制 —— 实际上它只是“可能扩容”，多数情况是零开销追加 - 验证方式：用
fmt.Printf("%p", &s[0])打印底层数组首地址，连续append若地址不变，说明没扩容 - 典型陷阱：在循环里反复
s = append(s, x)却没预设cap，导致多次 realloc + memmove，性能骤降
append 扩容的新容量不是固定翻倍，但行为可预测
Go 运行时根据当前 cap 决定新容量，不是简单 ×2。这个策略影响你能否复用底层数组、是否引发意外共享。
cap ：新 <code>cap通常是旧cap×2（如 4→8、512→1024）-
cap >= 1024：新cap≈ 旧cap+ 旧cap/4（如 1024→1280、2048→2560） - 最终值会向上对齐到内存页边界（如 8 字节对齐），所以
cap可能略大于理论值 - 不要依赖具体数值做判断 —— 比如用
==比较两个切片的底层数组地址来断定是否共享，扩容后地址必然不同，但未扩容时可能相同
复制是浅拷贝，引用类型元素仍指向同一底层结构
扩容时 Go 调用的是 memmove，逐字节复制切片头和元素值。这对 int、string 安全，但对指针、map、嵌套 slice 不是深拷贝。
- 示例：
s := []map[string]int{{"a": 1}}→t := append(s, map[string]int{"b": 2})→ 扩容后s[0]和t[0]仍是同一个map实例 - 后果：修改
t[0]["a"] = 99，s[0]["a"]同步变，不是 bug，是预期行为 - 若需隔离，必须手动深拷贝元素，或避免在切片中存可变引用类型
想真正“看到”复制过程，得用 unsafe 或调试器，但日常靠 cap 和地址观察更实用
你不需要读汇编或进 runtime 源码，就能确认复制是否发生。关键是养成检查两个信号的习惯：
- 扩容前后的
cap是否变化？if len(s) == cap(s)是唯一可靠触发条件 - 底层数组地址是否改变？
&s[0]（非空切片）或reflect.ValueOf(s).UnsafeAddr()可验证 - 别信
len变了就一定复制 ——len增加但cap没变，说明只是移动了“逻辑结尾”，没动内存
最常被忽略的点：截取操作（如 s[2:4]）不触发复制，但让多个切片共享同一底层数组；而 append 一旦扩容，就彻底切断这种共享 —— 这个切换点，才是内存复制真正起效的位置。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
