本文系统讲解 Go 切片中 length 与 capacity 的本质区别，阐明底层数组零值初始化机制、切片截取对容量的影响，以及为何 c[:2] 得到 [0,0]、c[2:5] 容量变为 3。
本文系统讲解 go 切片中 length 与 capacity 的本质区别，阐明底层数组零值初始化机制、切片截取对容量的影响，以及为何 `c[:2]` 得到 `[0,0]`、`c[2:5]` 容量变为 3。
在 Go 中，切片（slice）不是独立的数据容器，而是一个轻量级的三字段结构体（指针 + 长度 + 容量），它始终指向一个底层数组（underlying array）。理解 len 和 cap 的行为，关键在于把握这个“视图”与“底层数组”的关系。
首先澄清一个常见误区：make([]int, 0, 5) 并非创建“空数组”，而是分配一个长度为 5 的底层数组，并将其所有元素自动初始化为 int 类型的零值（即 0）。这是 Go 语言强制执行的内存安全机制——所有变量（包括底层数组元素）在声明/分配时都会被赋予其类型的零值。因此，尽管 b 的长度为 0（不可见任何元素），其背后已存在一个 [0, 0, 0, 0, 0] 的数组。
我们逐步分析示例代码：
b := make([]int, 0, 5) // 底层数组: [0 0 0 0 0], b.ptr → arr[0], len=0, cap=5 c := b[:2] // 截取前 2 个元素：c.ptr → arr[0], len=2, cap=5 → [0, 0] d := c[2:5] // 从 c 的索引 2 开始截取到索引 5（不包含）：d.ptr → arr[2], len=3, cap=3 → [0, 0, 0]
- c := b[:2] 并未“写入”或“清零”任何数据，它只是重新定义了一个视图起点和终点：c 的指针仍指向底层数组首地址，长度设为 2，因此可访问 arr[0] 和 arr[1] —— 它们本就是零值，故输出 [0, 0]。
- d := c[2:5] 是关键：此操作将 d 的指针移动到底层数组的 arr[2] 位置。此时：
- 长度 = 5 - 2 = 3（索引范围 [2,5) 包含 3 个位置）；
- 容量 = 底层数组总长度 - 新起点索引 = 5 - 2 = 3，因为 cap(d) 定义为“从 d 起始位置（arr[2]）到底层数组末尾（arr[4]）的元素总数”。
✅ 注意：这种默认切片表达式（s[i:j]）不显式控制容量，新切片的容量由底层数组边界决定。若需精确控制容量（例如避免意外共享大量底层数组内存），应使用完整切片表达式：s[i:j:k]，其中 k 指定新切片的容量上限（k - i）。例如 c[2:5:5] 容量仍为 3，但 c[2:3:4] 将得到 len=1, cap=2。
一个典型工程隐患正源于此：若从一个大容量切片（如 make([]byte, 0, 1<<20)）反复截取小片段（如 s[:100]），该小切片仍持有 1MB 底层数组的引用，导致 GC 无法回收，引发隐性内存泄漏。解决方案是通过重新分配切断引用：
// 安全复制，释放原始底层数组引用
safe := append([]int(nil), d...) // 创建新底层数组，仅拷贝 d 的元素
fmt.Printf("safe: len=%d, cap=%d\n", len(safe), cap(safe)) // len=3, cap≈3（通常按需分配）总结而言，切片的 len 决定当前可读写范围，cap 决定最大可扩展空间，二者均由底层数组的物理布局与切片视图的起止位置共同决定。掌握这一机制，是写出高性能、低内存开销 Go 代码的基础。
