Go Slice 从 0 到底层：先搞懂“为什么”，再记 len、cap

学习 Slice 不需要先创建数组，也不需要先背底层结构。最常见的方式，是直接写出一组数据：

s := []int{10, 20, 30}
fmt.Println(s) // [10 20 30]

如果一开始还没有数据，可以用 make（Go 内置的创建函数）得到一个空 Slice，再用 append（Go 内置的追加函数）逐个加入元素：

s := make([]int, 0)
s = append(s, 10)
s = append(s, 20)
s = append(s, 30)

下面代码不是在说“创建 Slice 必须先创建数组”。这里的 a 代表已经存在的一整批数据，s 代表现在只想处理其中一部分：

a := [8]int{10, 20, 30, 40, 50, 60, 70, 80}
s := a[2:5] // 只看 30、40、50

a[2:5] 遵守“左边包含、右边不包含”：从下标 2 开始，取下标 2、3、4，不取下标 5。它更像在 Excel 表格中框出一个选区，而不是复制一份新表格。

为什么不默认复制？

假设已有 100 万个元素，现在只处理第 100 到 199 个。直接切出 data[100:200]，只需建立一个很小的描述；如果每次都复制，还要重新申请内存并搬运 100 个元素。数据越大、切分越频繁，这个差距越明显。

既然 Slice 只是一个选区，Go 至少要记住三件事：选区从哪里开始、现在框了几个元素、追加数据时原数组最多还能利用到哪里。于是可以一步步得到 pointer（起点地址）、len（length 的缩写，表示当前长度）和 cap（capacity 的缩写，表示最大可利用容量）。

这三个信息合起来，正式名称叫 Slice Header（切片头，也就是记录这个选区信息的小结构）。它在当前 Go 运行时实现中可理解为下面三个字段；其中 unsafe.Pointer 是只记录内存地址、不附带元素类型的底层指针：

type slice struct {
    array unsafe.Pointer // 指向底层数组中窗口起点
    len   int            // 当前能直接访问的元素个数
    cap   int            // 从起点到当前底层数组末尾最多还能容纳多少元素
}

不要先背公式：直接从数组里数出 3 和 6

仍看 s := a[2:5]。当前选中的下标是 2、3、4，所以 len 是 3；从起点下标 2 一直到数组末尾，还能利用 2、3、4、5、6、7 六个位置，所以 cap 是 6。cap 不是“还剩几个空位”，而是从 Slice 起点开始的整个可利用范围。

先做一个只改变创建方式的对照

own := []int{30, 40, 50}
own[0] = 999

view := a[2:5]
view[0] = 999

区别不在“Slice 能不能修改”，而在它们是否指向同一个底层数组。底层数组就是实际连续存放元素的那块数据；多个 Slice 可以用不同选区共享它。

base := []int{10, 20, 30, 40, 50}
left := base[1:3]  // [20 30]，len=2，cap=4
right := base[2:5] // [30 40 50]
left[1] = 999       // 实际改的是 base[2]

此时 base 变成 [10 20 999 40 50]，right[0] 也变成 999。原因不是“Slice 互相复制”，而是它们的窗口重叠在同一个底层数组上。

完整切片表达式不是复制数据。它只是把 cap 截短，让下一次越过 cap 的 append 更早触发扩容，从而与原数组分离。

传给函数为什么也会改到外面？

func change(s []int) {
    s[0] = 999
}

nums := []int{10, 20, 30}
change(nums) // nums 变成 [999 20 30]

Go 的参数传递仍然是值传递：函数得到的是 Slice Header 的一份副本，不是全部元素的副本。两份 Header 中的地址仍指向同一个底层数组，所以通过其中一份修改元素，另一份也能看到。

append（Go 内置的追加函数）会把新元素放到 Slice 末尾。容量不足时，它会进入 growslice（运行时负责扩大 Slice 容量的函数），再通过 memmove（复制连续内存的底层操作）搬走旧元素。

为什么“改没改原数组”不能只看 append 这个动作

要看 append 前的 len 与 cap。如果容量够，append 复用原数组，其他共享者可能看到变化；如果容量不够，append 换新数组，之后的修改通常与旧数组分离。

growslice 先调用 nextslicecap（根据新长度和旧容量计算目标容量的函数）。当前实现的主线可以简化为：

func nextslicecap(newLen, oldCap int) int {
    newcap := oldCap
    doublecap := newcap + newcap

    if newLen > doublecap {
        return newLen // 一次追加很多，直接容纳请求
    }

    const threshold = 256
    if oldCap < threshold {
        return doublecap // 小 Slice 倾向 2 倍
    }

    for newcap < newLen {
        newcap += (newcap + 3*threshold) >> 2
    }
    return newcap
}

当容量刚超过阈值时，额外的 192 让增长率仍明显高于 1.25；随着容量越来越大，192 的影响变小，增长率才逐渐接近 1.25。

逻辑容量还不是最终分配结果。Go 运行时会把 newcap × 元素大小 换算成字节数，再通过 roundupsize（把请求字节数向上对齐的函数）匹配 size class（内存分配器预先划分的字节规格），最后用“实际字节数 ÷ 元素大小”反推出真正的 cap。mallocgc 是运行时申请这块堆内存的函数。

元素里有没有指针，为什么会影响分配

扩容的真实成本

• 申请一块更大的连续内存；
• 把旧的 len 个元素复制过去，复制量约为 len × sizeof(T)；
• 更新 Slice Header 指向新数组；
• 旧数组只有在没有任何引用后，才可能被 GC 回收。

所以单次扩容是 O(n)（成本随元素数量近似线性增长），但容量按比例增长后，连续追加的均摊复杂度仍可视为 O(1)（把多次操作合起来看，单次平均成本近似不随数据量增长）。

最容易误判的是“Slice 已经很小，所以占用的内存也很小”。例如从 100 兆字节（MB）的数组中只保留 10 字节，只要 Slice 记录的地址仍指向大数组，即使 len 变成 0，那块大数组仍可能被保留；需要长期保存少量数据时，应显式复制到独立的小数组。

保存为 main.go，执行 go run main.go。地址值每次运行不同，但“扩容前相同、扩容后分离”的关系不变。

package main

import "fmt"

func main() {
    base := make([]int, 2, 4)
    base[0], base[1] = 10, 20

    alias := base
    fmt.Printf("初始  base=%v len=%d cap=%d addr=%p\n",
        base, len(base), cap(base), &base[0])
    fmt.Printf("初始 alias=%v len=%d cap=%d addr=%p\n",
        alias, len(alias), cap(alias), &alias[0])

    // 容量够：仍使用同一底层数组。
    base = append(base, 30)
    alias[0] = 99
    fmt.Println("未扩容后 base =", base) // [99 20 30]

    // 一次追加到超过 cap：触发扩容并复制。
    base = append(base, 40, 50)
    base[0] = 777
    fmt.Printf("扩容  base=%v len=%d cap=%d addr=%p\n",
        base, len(base), cap(base), &base[0])
    fmt.Printf("旧的 alias=%v len=%d cap=%d addr=%p\n",
        alias, len(alias), cap(alias), &alias[0])

    // 完整切片表达式：限制 cap，强制下一次 append 分离。
    parent := []int{1, 2, 3, 4}
    child := parent[:2:2]
    child = append(child, 100)
    fmt.Println("parent =", parent) // [1 2 3 4]
    fmt.Println("child  =", child)  // [1 2 100]
}

1. Slice Header：只描述数组窗口，不直接保存元素。
2. append：必须接住返回值；是否扩容取决于新长度和 cap。
3. 扩容策略：小容量倾向 2 倍，大容量平滑过渡到约 1.25 倍；一次追加很多则至少直接容纳 newLen。
4. 实际容量：目标 cap × 元素大小，再按分配器 size class 对齐。
5. 复制成本：扩容时分配新数组并 memmove 旧元素，单次 O(n)、连续 append 均摊 O(1)。
6. 共享风险：子 Slice、函数参数、Header 复制都可能继续指向同一数组。
7. 内存风险：小 Slice 可能留住大数组；缩短 len 不等于释放底层内存。
8. 隔离手段：需要真正独立就 copy / slices.Clone；完整切片表达式只限制 cap。

Slice 适合处理“元素按顺序存放，数量可能变化”的数据。真正做业务时，不只要问“能不能 append”，还要问“能否预估数量”、“是否允许共享数组”和“这块内存要保留多久”。

本页以 Go 官方语言规范和 runtime 源码为依据。语言语义相对稳定，扩容阈值、公式、内存分配细节可能随版本变化。

• Go Language Specification：Slice types
• Go Language Specification：append 与 copy
• Go runtime：slice.go（growslice / nextslicecap）
• Go runtime：msize.go（roundupsize）