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]。

编译器优化 on Zampo Blog

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

数组是值，长度是类型