17370845950

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 返回的新切片指向**全新的底层数组**，原切片仍指向旧数组——它们不再共享数据。这是常见陷阱：

错误示例：

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 元素，另一个也能看到——这符合预期，也提醒你注意并发读写风险。