---
tags: [go/lang, slice, memory-allocation, append-growth, array]
create time: 2026-08-08 19:00
update time: 2026-08-08 19:00
---

# 切片底层实现

## 概述

切片（Slice）是 Go 语言中最常用的集合抽象，它不是简单的数组别名，而是一段指向连续内存的轻量级描述符。理解切片的底层结构——指针、长度、容量——以及 `append` 扩容时的精确策略，是写出高性能 Go 代码的基础，也是后端面试中经久不衰的核心考点。本文将深入到 runtime 源码级别，讲透切片的每一个行为细节。

> [!NOTE] 一个关键认知
> 切片本身不是一个容器，它是容器的"遥控器"——三个字段操控着一块共享的底层数组。理解了这一点，几乎所有切片相关的坑都迎刃而解。

## 核心原理

### 切片的内部结构

在 Go 的运行时中，切片的底层结构由 `reflect.SliceHeader` 和编译期直接操作的 `slice` struct 共同定义。你可以把切片想象成一个三字段的小对象：

```mermaid
graph TD
    A["slicestruct<br/>ptr / len / cap"] --> B["底层数组 backing array<br/>[ elem0 | elem1 | elem2 | ... ]"]
    
    subgraph "切片头部 24 bytes x64"
        A
    end
    
    subgraph "堆或栈上的连续内存"
        B
    end
    
    A -.->|"ptr: 首元素地址"| C["elem0"]
    style A fill:#e3f2fd,stroke:#1565c0,color:#000
    style B fill:#fff3e0,stroke:#e65100,color:#000
```

三个字段各有其责：

| 字段 | 大小 (x64) | 含义 | 可达性分析 |
|------|-----------|------|----------|
| `ptr` | 8 bytes | 指向底层数组的第一个元素 | GC 根节点 |
| `len` | 8 bytes | 当前可访问的元素个数 | 普通整数 |
| `cap` | 8 bytes | 底层数组的总容量 | 普通整数 |

切片只有 `len` 个元素对调用者可见，`cap` 之外的内存虽然存在但不可通过索引访问。这种设计让切片可以高效地表示子数组视图。

> [!TIP] 面试常考点
> `unsafe.Sizeof(VarSlice)` 在 64 位平台上永远是 24，无论切片里存了多少元素。切片头很小，真正的数据在别处。

### make() vs 切片字面量 vs nil

创建切片有三种方式，它们在零值和语义上有本质区别：

```go
var s1 []int       // nil slice，ptr=nil, len=0, cap=0
s2 := make([]int, 0)  // empty slice，ptr=new(array), len=0, cap=1
s3 := []int{}          // empty slice，与 s2 等价
```

三种状态的区别：

| 创建方式 | ptr | len | cap | `s == nil` | 适用场景 |
|---------|-----|-----|-----|-----------|---------|
| `var s []int` | nil | 0 | 0 | true | 延迟初始化、可选参数默认值 |
| `make([]int, 0)` | new(array) | 0 | 1 | false | 需要立即 append 的场景 |
| `[]int{}` | new(array) | 0 | 1 | false | 明确表达"我需要一个空切片" |

为什么区分 nil slice 和 empty slice？因为 JSON 序列化行为不同：`encoding/json` 将 nil slice 编码为 `null`，empty slice 编码为 `[]`。这在 API 设计中很重要。

**nil slice 的优势**：`append` 到 nil slice 上会安全地分配一个新数组，这是 Go 的标准用法。

```go
var result []string
result = append(result, "hello")  // 完全合法，自动分配
_ = result  // ["hello"], cap=1
```

### append 扩容策略详解

`append` 是切片最核心的操作，它的行为取决于剩余容量是否充足：

```
若 len(s) < cap(s):
    → 直接在底层数组的[len]位置写入新元素
    → len++，返回同一底层数组的切片
    → ptr/底层数组不变，仅更新 len

若 len(s) == cap(s):
    → 必须分配更大的底层数组
    → 旧数组内容全部拷贝到新数组
    → 写入新元素，返回新的切片头
    → ptr 改变，len 和 cap 都改变
```

扩容时新容量的计算是面试官最喜欢深挖的部分。Go 1.18 之后使用以下公式（简化自 `runtime/growalloc.go`）：

```
当新需求 cap < 256 时：newCap = oldCap * 2
当新需求 cap >= 256 时：newCap = oldCap + oldCap/4

即 growth ratio = 1.25（每次增长约 25%）
```

但这个公式有一个重要的修正机制。实际代码中的逻辑分四步走：

1. 先按上述公式算出 `newCap`
2. 如果 `newCap` 小于目标 `cap`（边界情况），则将 `newCap` 翻倍直到满足要求
3. 如果旧 `cap` 太小而目标 `cap` 太大（例如从 0 追加 1000 个元素），直接用目标 `cap`
4. 最终用 `math.MaxInt` 做兜底保护，防止整数溢出

这个设计非常实用：小切片翻倍可以尽快达到可用规模，大切片 25% 的增长率则避免了过度分配造成的内存浪费。一个容量 10000 的切片扩容时只多分配 2500，而不是翻倍到 20000。

> [!WARNING] 常见误区
> 很多人以为所有情况都是翻倍扩容，这是基于早期 Go 版本的印象。实际上从 Go 1.18 起，≥256 的阈值就是 1.25x 增长率。

### append 扩容演示

```go
func main() {
    s := make([]int, 0, 2)  // cap=2
    fmt.Println(cap(s))      // 2

    s = append(s, 1, 2)     // len=2, cap=2，刚好满
    s = append(s, 3)        // 触发扩容：2*2=4, newCap=4
    fmt.Println(cap(s))      // 4

    s = append(s, 4, 5, 6)  // 触发扩容：4+4/4=5, newCap=5
    fmt.Println(cap(s))      // 8（实际取min(maxCap,cap*2)的上限处理）

    s = append(s, 7)        // 再次触发扩容
    fmt.Println(cap(s))      // 16

    s = append(s, 8)        // cap=16>=256不成立，继续翻倍
    fmt.Println(cap(s))      // 32

    // 当 cap 达到 256 后切换为 1.25x 增长
    s = make([]int, 0, 300)
    for i := 0; i < 10; i++ {
        s = append(s, 0)
        if i > 0 && i%3 == 0 {
            fmt.Printf("cap: %d\n", cap(s))
        }
    }
}
// cap: 375 (300 + 300/4)
// cap: 468 (375 + 375/4)
// cap: 585 (468 + 468/4)
```

### 数组到切片的隐式转换

Go 允许通过切片表达式将完整数组转为切片：

```go
arr := [5]int{1, 2, 3, 4, 5}
s := arr[:]   // 等价于 arr[0:5]

fmt.Printf("type: %T\n", s)  // type: []int

// 底层关系：s.ptr == &arr[0]，len=5，cap=5
```

关键点：**数组到切片的转换只是构造了一个切片头，底层数组本身不参与 GC 引用计数调整**。数组如果是栈上的局部变量，编译器逃逸分析决定它是否被分配到堆上。

切片表达式还有更强大的形式 `[low : high : max]`（三索引切片）：

```go
a := make([]byte, 5)  // [0 0 0 0 0], len=5, cap=5
s1 := a[1:4]           // [0 0 0], len=3, cap=4 (cap = 5-1)
s2 := s1[0:2]          // [0 0], len=2, cap=2 (受 s1.cap 限制)

// 三索引写法的显式写法：
s3 := a[1:4:5]         // [0 0 0], len=3, cap=4
s4 := a[1:4:5][:3]     // 这会 panic！s4.cap=4 但试图访问索引3
```

三索引切片的 `max` 参数限制了切片的最大容量，防止后续操作越界到原始数组的后半段。

> [!TIP] 面试加分项
> 指出三索引切片是 Golang 1.20 之前的主要做法，后来官方推荐用显式的 `s[:newLen:newCap]` 替代，语法更一致。

## 代码示例

### append 共享底层数组的经典陷阱

```go
func SplitAndSum(input []int) ([][]int, int) {
    halves := [][]int{
        input[:len(input)/2],  // 前半段
        input[len(input)/2:],   // 后半段
    }
    sum := 0
    for _, h := range halves {
        for _, v := range h {
            sum += v  // 累加求和
        }
    }
    return halves, sum
}

func main() {
    nums := []int{1, 2, 3, 4, 5, 6}
    parts, total := SplitAndSum(nums)
    parts[0][0] = 99  // ⚠️ 修改前半段会影响 original nums!
    // 因为 halves 和 nums 共享同一个底层数组
    _ = total
}
```

这段代码暴露了切片的一个本质特性：**多个切片可以同时引用同一块底层内存**。当你需要"分割"数据但不希望后续修改互相影响时，必须先 `copy`：

```go
first := make([]int, len(input)/2)
copy(first, input[:len(input)/2])  // 深拷贝，断开共享
second := input[len(input)/2:]
_ = first
_ = second
```

### 预分配 vs 动态扩容的性能差异

```go
func appendWithoutPrealloc(n int) []int {
    var result []int  // 从 nil 开始，逐步扩容
    for i := 0; i < n; i++ {
        result = append(result, i)
    }
    return result
}

func appendWithPrealloc(n int) []int {
    result := make([]int, n)  // 一次性分配
    for i := 0; i < n; i++ {
        result[i] = i
    }
    return result
}

// 性能差距显著：对于百万级切片，
// 预分配版本减少了多次 malloc/copy 的开销
// 且避免了中间态垃圾对象的产生
```

预分配的核心优势有两点：一次分配零拷贝 vs 多次分配带拷贝。如果大致知道最终大小，`make([]T, 0, expectedSize)` 是最佳实践。

### 切片重切的副作用演示

```go
func DemonstrateSharing() {
    orig := []byte("Hello, World!")  // cap=13
    short := orig[:5]                // "Hello", 共享底层数组

    // 如果给 short 预留空间并 append，会覆盖 orig 的内容
    saved := short[:cap(short)]      // 扩展回 full length
    copy(saved, "Hi")               // orig[0:3] 也被改成 "Hi"
    
    println(string(orig))  // "Hi, World!" —— 被意外修改了！
}
```

这是一个在 real world 项目中真实出现过的 bug。防御方式是避免将短切片以大容量形式暴露给外部代码。

## 实践场景

### 面试高频问题清单

**Q1: `var s []int` 和 `s := []int{}` 有什么区别？**
两者功能完全等价，区别在于语义表达。`var s` 暗示"延迟初始化"，`[]int{}` 暗示"我现在就要一个空切片"。JSON 序列化时前者输出 `null` 后者输出 `[]`。

**Q2: append 会不会修改原切片？**
这要看原切片是否已满。如果 `len < cap`，append 直接在原底层数组上操作，原切片会自动看到新增元素（因为 len 会变）。如果触发了扩容，则原切片不受影响，因为底层数组已经换了。

**Q3: 如何判断两个切片是否共享底层数组？**
没有内置方法，只能通过逻辑推理。经验法则：任何通过切片表达式产生的新切片，只要范围与原切片有重叠，就必然共享。

**Q4: 切片的零值是 nil 吗？nil 切片能用吗？**
是的。nil 切片可以使用 `append`、`len()`、`range` 等操作，但不能 `copy(dst, nilSlice)`——目标必须非 nil 且有足够容量。

### 实战建议

- **函数返回值用 pre-allocated 而非 nil**：如果你知道会往返回值 append 数据，用 `make([]T, 0, hint)` 比 `var ret []T` 更高效。
- **不要把切片内部缓冲区暴露出去**：HTTP handler 接收 request body 后，应该 `copy` 一份所需数据再传给 goroutine，否则原始缓冲区可能被复用覆盖。
- **`bytes.Buffer` vs `[]byte`**：需要反复追加字节的数据结构时，`bytes.Buffer` 内部用了 `[]byte` 并管理了自己的扩容策略，通常比手动 append 更安全。
- **`s = s[:0]` 重置技巧**：比重新 `make` 更快，因为底层数组保持不变，下次 append 不会触发额外分配。适合缓存复用的场景。

```go
// 高性能的缓存模式
var cache []int
cache = cache[:0]  // 重置长度，保留底层数组
for _, item := range items {
    cache = append(cache, process(item))
}
// 下一次调用 cache[:0] 即可复用已分配的内存
```

## 关联笔记

- [[Map 底层实现]] — Slice 是 Map bucket 内部的数组类型，理解切片有助于理解 Map 的扩容和数据组织
- 00.Go/concurrency/Goroutine 调度模型 — Goroutine 参数传递中使用切片的注意事项
- 00.Go/runtime/三色标记GC原理 — 切片作为 GC root 参与可达性分析的过程