Go 里真正难懂的不是 slice，是它背后的数组

Sat, 23 May 2026 09:45:00 +0800

一次 append，把原来的数据改坏了。

代码看起来很普通：从一个 slice 里切一段出来，往这段里追加一个元素。你以为只是改了新变量，结果回头一看，原 slice 里的某个位置也变了。

这类问题很烦，因为它不像空指针那样直接炸给你看。它更像一个安静的错：数据还在，长度也对，测试偶尔过，线上某个分支才露出一点不对劲。

很多人这时会说：slice 是引用类型。

这句话不算完全错，但太粗糙。粗糙到一定程度，就会害人。

Go 里真正值得理解的，不是“slice 是不是引用类型”，而是：数组负责装数据，slice 只负责描述一段数组。数组给机器确定性，slice 给程序员弹性。Go 同时保留这两个东西，不是语言设计多此一举，而是它不愿意把这两种需求混成一团。

理解这一点，后面的 append、扩容、子切片、内存保留，都会变得顺很多。

数组很硬，但这正是它的价值

Go 的数组不是“指向一串元素的地址”。数组变量代表的是整个数组。

[3]int 和 [4]int 是两个不同类型。长度进类型，元素连续排列，赋值和传参都会复制整个数组。这些特性放到业务代码里看，确实不够灵活：函数想接收任意长度的整数列表，不能写一个 [N]int 让 N 动起来；大数组传来传去，也会带来复制成本。

但站在机器这边看，数组非常舒服。

长度确定，布局连续，元素类型一致。编译器知道它有多大，CPU 也喜欢顺着连续内存往前读。很多时候，所谓“底层性能”，并不是某个神秘技巧，而是数据摆得足够朴素，机器不用猜。

所以数组不是 Go 里被 slice 淘汰掉的旧家具。它更像地基。

你日常很少把数组当动态集合用，不代表它不重要。恰恰相反，slice 的一切便利，都建立在底层数组这块“确定形状的钢板”上。

slice 本身并不装元素。

在 Go 1.25.4 的 runtime 源码里，slice 的核心结构就是三个字段：

1
2
3
4
5


type slice struct {
 array unsafe.Pointer
 len int
 cap int
}

可以把它理解成一张小纸条：