Go 切片扩容策略理解 append 的内存行为

go arr := [5]int{1, 2, 3, 4, 5} s := arr[1:4] fmt.Println(len(s), cap(s)) // 输出：3 4

`s` 的长度为 3，包含元素 `2, 3, 4`；容量为 4，因为底层数组从索引 1 到末尾还有 4 个位置可用。

### 2. `append` 的触发条件

当你向切片追加元素时，Go 会检查：

-   **现有容量够用**：`len(slice) + 新元素数量 ≤ cap(slice)`  
    直接在底层数组上追加，返回的切片依然共享同一个底层数组。
-   **容量不足**：`len(slice) + 新元素数量 > cap(slice)`  
    必须分配一块更大的新数组，将原数据复制过去，再追加新元素，最后返回指向新数组的切片。

下面通过一段代码直观感受两种情况的差异：

```go
func main() {
    // 容量足够
    s1 := make([]int, 2, 5)
    s1 = append(s1, 10)
    fmt.Println(len(s1), cap(s1)) // 3 5   没有扩容

    // 容量不足，触发扩容
    s2 := make([]int, 2, 3)
    fmt.Printf("原切片指针: %p\n", &s2[0])
    s2 = append(s2, 10, 20)       // len=4 > cap=3
    fmt.Printf("新切片指针: %p\n", &s2[0]) // 指针已改变
    fmt.Println(len(s2), cap(s2))
}

3. 扩容策略：新容量是如何计算的

这是开发者最关心的部分。Go 的扩容规则在版本演进中有过调整，以下以 Go 1.18+ 当前主流版本 的规则为准。

当需要扩容时，伪代码逻辑如下：

newcap := old.cap
doublecap := newcap + newcap
if cap > doublecap {
    newcap = cap
} else {
    if old.cap < 1024 {
        newcap = doublecap
    } else {
        for 0 < newcap && newcap < cap {
            newcap += newcap / 4
        }
        if newcap <= 0 {
            newcap = cap
        }
    }
}
// 之后会根据元素大小、内存对齐进行圆整计算，得到最终容量。

关键点解读：

• 所需容量远大于原容量：如果一次性 append 大量元素，使得所需容量超过原容量的两倍，则直接使用所需容量作为新容量。
• 原容量小于 1024：新容量直接翻倍（原容量 × 2）。
• 原容量大于等于 1024：新容量循环增加 25%（即每次增加原容量的 1/4），直到能够装下所有元素。
• 内存对齐微调：出于内存分配效率的考虑，Go 会根据元素类型的大小进行对齐调整，因此最终输出的 cap 可能比上述计算的值略大或略小一点。这部分属于实现细节，不影响整体理解。

示例：验证扩容规律

func main() {
    s := make([]int, 0)
    oldCap := cap(s)
    for i := 0; i < 2000; i++ {
        s = append(s, i)
        if newCap := cap(s); oldCap != newCap {
            fmt.Printf("len: %-4d cap: %-4d 增长倍数: %.2f\n", len(s), newCap, float64(newCap)/float64(oldCap))
            oldCap = newCap
        }
    }
}

运行这段代码（Go 1.18+）你会观察到：

• 在容量较小时，每次增长倍数为 2.00。
• 当容量超过 1024 后，增长倍数逐步趋近于 1.25。
• 偶尔会出现容量小于预期的现象（如 1280 而非预期的 1248），这就是内存对齐造成的微调。

4. 扩容对内存和共享行为的影响

内存重新分配与旧数组的回收

一旦切片扩容，Go 会分配新的底层数组，并将旧数据复制过去。原有的底层数组如果没有其他引用，最终会被垃圾回收器清理。因此，频繁的扩容会引发多次内存分配和复制，对性能有一定影响。

多个切片共享底层数组的陷阱

当两个切片引用同一底层数组时，对一个切片的修改可能“意外”影响另一个切片。扩容可能会切断这种关联：

s1 := []int{1, 2, 3, 4}
s2 := s1[0:2]         // s2 与 s1 共享底层数组
s2 = append(s2, 99)   // len(s2)=3, cap 足够，直接在共享数组上修改
fmt.Println(s1)       // [1 2 99 4]   s1 被连带修改！

s2 = append(s2, 100)  // 可能触发扩容（取决于 s1 的容量）
// 如果发生扩容，s2 指向新数组，s1 不再受影响

因此，当你希望隔绝修改时，最好的方式是显式使用 copy 创建独立副本，或在已知容量需求时预先分配足够大的切片。

5. 最佳实践与性能建议

• 预分配容量：如果能够预估最终元素数量，使用 make([]Type, 0, cap) 一次性分配足够的容量，避免多次扩容带来的内存分配和复制开销。
• 警惕 append 的返回值：每次调用 append 都应接收其返回值，即使容量未满也要接收，这样才能保证代码的一致性，并避免因未来扩容导致的指针失效。
• 合理使用 copy：当需要两个切片互不干扰时，不要依赖“暂时共享，等扩容就自然分开”的侥幸心理，显式使用 copy 创建副本是最稳妥的做法。

// 高效收集已知数量的元素
data := make([]int, 0, 1000)
for i := 0; i < 1000; i++ {
    data = append(data, process(i)) // 全程无扩容
}

// 创建独立副本
src := []int{1, 2, 3}
dst := make([]int, len(src))
copy(dst, src)