为什么要使用数组而不是切片？

咸昊昊

2023-03-14

问题内容：

我一直在阅读Go，并为这个基本问题感到困惑。

在Go中，很明显，切片更灵活，并且在需要一系列数据时通常可以代替数组使用。

阅读了大多数文档，他们似乎鼓励开发人员只使用切片而不是数组。我得到的印象是，创建者可以简单地将数组设计为可调整大小的，而无需整个切片部分即可完成。实际上，这样的设计会使该语言更易于理解，甚至鼓励使用更多惯用的代码。

那么，为什么创建者首先要允许数组呢？什么时候可以使用数组代替切片？有没有一种在切片上使用数组的情况会很 吸引人的情况 ？

当我查阅官方文档（http://golang.org/doc/effective_go.html#arrays）时，发现的唯一有用的部分是：

数组在计划内存的详细布局时很有用，有时可以帮助避免分配，但首先，它们是切片的基础。

他们接着讨论了数组作为值如何昂贵，以及如何使用指针模拟C样式的行为。即使这样，他们也以明确的建议结束了数组部分：

但是，即使这种样式也不是惯用的Go。请改用切片。

那么，有什么真正的例子是“规划内存的详细布局”或“帮助避免分配”的，这些切片将不适合？

问题答案：

正如Akavall所说，数组是可哈希的。这意味着它们可以用作地图的键。

它们也通过价值传递。每次将其传递给函数或将其分配给另一个变量时，它都会对其进行完整复制。

它们可以通过编码/二进制序列化。

它们还可以用于控制内存布局。由于它不是引用，因此当将其放置在结构中时，它将分配那么多的内存作为该结构的一部分，而不是像切片那样将等效的指针放在那里。

最重要的是，除非您知道自己在做什么，否则不要使用数组。

哈希/可序列化都很好，但是我不确定它们是否确实具有吸引力

如果您想拥有md5散列图，该怎么办？无法使用字节片，因此您需要执行以下操作来绕过类型系统：

// 16 bytes
type hashableMd5 struct {a, b, c, d, e, f, g, h, i, j, k, l, m, n, o, p byte}

然后为其创建序列化函数。可哈希数组意味着您可以仅将其称为[16] byte。

听起来越来越接近C的malloc，sizeof

不，这与malloc或sizeof无关。这些是分配内存并获取变量的大小。

但是，CGo是此的另一个用例。cgo命令创建的类型与其对应的C类型具有相同的内存布局。为此，有时需要插入未命名的数组进行填充。

如果问题可以用…来解决…使用切片的性能为零/微不足道…

数组还可以防止间接使某些类型的代码更快。当然，这是一个很小的优化，几乎在所有情况下都是微不足道的。