Go 数组为什么这么硬？因为它要把边界写进类型里

Sat, 23 May 2026 11:55:00 +0800

同样是复制，一个 [32]byte 的 hash 往往很安全，一个 struct 里的 [4096]int 却可能把性能拖得很难看。

这不是 Go 数组“好不好用”的问题，而是你有没有把它当成正确的东西。

很多 Go 开发者平时几乎不直接写数组。业务列表用 slice，字典用 map，缓冲区也经常一上来就是 []byte。于是数组很容易被误解成 slice 背后的旧零件：知道有这么个东西，但最好别碰。

这个判断太粗了。

数组在 Go 里不是为了替代 slice 做动态集合。它的价值恰恰在于“不灵活”：长度固定、类型固定、赋值复制、元素可比较时整体可比较。它把一块数据的形状写死，让函数边界、类型系统和编译器都少猜一点。

数组是值，长度是类型

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

这句话听起来像语法点，实际影响很大。你把一个数组赋给另一个变量，复制的是整个数组；你把数组传给函数，函数收到的也是一份数组值。除非你显式传 *[N]T，否则函数里改不到调用方那份数组。

1
2
3
4
5
6


func ValueSemantics() ([3]int, [3]int) {
 original := [3]int{1, 2, 3}
 copyOfOriginal := original
 copyOfOriginal[0] = 99
 return original, copyOfOriginal
}

返回的第一份还是 [1 2 3]，第二份才是 [99 2 3]。

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 不是数组，是一张小纸条

slice 本身并不装元素。

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

1
2
3
4
5


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

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

数组 on Zampo Blog

Go 数组为什么这么硬？因为它要把边界写进类型里

数组是值，长度是类型

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

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

slice 不是数组，是一张小纸条