append扩容时会重新分配底层数组，新切片指向新地址，旧切片不再共享数据；预分配cap可避免多次realloc提升性能；扩容复制为浅拷贝，引用类型元素仍指向同一底层结构。
Go 语言中，切片（slice）的 append 操作看似简单，但背后涉及底层数组扩容策略、内存分配和引用关系，理解它对写出高效、安全的代码很关键。
append 不是“总复制”，但扩容时会重新分配底层数组
切片本质是三个字段的结构体：ptr（指向底层数组的指针）、len（当前长度）、cap（容量）。只要 len ，append 就直接在原数组末尾写入，不分配新内存；一旦 len == cap，就必须扩容。
扩容不是按固定倍数增长，而是有策略的：
- 当原
cap 时，新cap翻倍（×2） - 当
cap >= 1024时，每次增加约 25%（即cap += cap / 4），避免过度分配 - 最终新容量会向上取整到内存对齐边界（如 8 字节对齐），实际值可能略大于理论值
扩容后旧切片可能“失效”，别依赖原底层数组
一旦发生扩容，append 返回的新切片指向**全新的底层数组**，原切片仍指向旧数组——它们不再共享数据。这是常见陷阱：
立即学习“go语言免费学习笔记（深入）”；
错误示例：
s := []int{1, 2, 3}
t := s
s = append(s, 4) // 此时很可能扩容 → s 指向新数组
fmt.Println(t) // 输出 [1 2 3]，没变
fmt.Println(s) // 输出 [1 2 3 4]，但和 t 无关了
所以：不要假设 append 后旧变量还能反映新内容；若需共享修改，应统一使用返回值。
预分配容量可避免多次扩容，提升性能
如果知道最终长度，用 make([]T, len, cap) 预设足够 cap，能跳过中间多次 realloc。例如批量构建 1000 个元素：
- 不预分配：
s := []int{}→ 可能触发约 10 次扩容（2→4→8→…→1024） - 预分配：
s := make([]int, 0, 1000)→ 一次分配，零额外拷贝
尤其在循环中频繁 append 时，预分配收益明显。基准测试常显示 2–5 倍性能提升。
底层 copy 是浅拷贝，注意引用类型元素
扩容时，Go 用 memmove 把旧数组内容**逐字节复制**到新地址。这对基本类型（int、string）没问题；但若切片元素是指针、map、slice 或 struct 含这些字段，复制的只是“引用值”，不是深层数据。
这意味着：扩容不会触发深拷贝，原切片和新切片中对应位置的 map/slice 仍指向同一底层结构。修改其中一个的 map 元素，另一个也能看到——这符合预期，也提醒你注意并发读写风险。
