引言
除非您正在对服务进行原型设计，否则您可能会关心应用程序的内存使用情况。内存占用更小，基础设施成本降低，扩展变得更容易/延迟。
尽管 Go 以不消耗大量内存而闻名，但仍有一些方法可以进一步减少消耗。其中一些需要大量重构，但很多都很容易做到。
预先分配切片
数组是具有连续内存的相同类型的集合。数组类型定义指定长度和元素类型。数组的主要问题是它们的大小是固定的——它们不能调整大小，因为数组的长度是它们类型的一部分。
与数组类型不同，切片类型没有指定长度。切片的声明方式与数组相同，但没有元素计数。
切片是数组的包装器，它们不拥有任何数据——它们是对数组的引用。它们由指向数组的指针、段的长度及其容量（底层数组中的元素数）组成。
当您追加到一个没有新值容量的切片时 - 会创建一个具有更大容量的新数组，并将当前数组中的值复制到新数组中。这会导致不必要的分配和 CPU 周期。
为了更好地理解这一点，让我们看一下以下代码段：
输出如下：
Address: 0xc0000160c8, Length: 1, Capacity: 1, Values: [0]
Address: 0xc0000160f0, Length: 2, Capacity: 2, Values: [0 1]
Address: 0xc00001e080, Length: 3, Capacity: 4, Values: [0 1 2]
Address: 0xc00001e080, Length: 4, Capacity: 4, Values: [0 1 2 3]
Address: 0xc00001a140, Length: 5, Capacity: 8, Values: [0 1 2 3 4]
查看输出，我们可以得出结论，无论何时必须增加容量（增加 2 倍），都必须创建一个新的底层数组（新的内存地址）并将值复制到新数组中。
有趣的事实是，容量增长的因素曾经是容量 <1024 的 2 倍，以及 >= 1024 的 1.25 倍。从 Go 1.18 开始，这已经变得更加线性。
查看上述基准，我们可以得出结论，将值分配给预分配的切片和将值附加到切片之间存在很大差异。
两个 linter 有助于预分配切片：
结构中的顺序字段
您之前可能没有想到这一点，但结构中字段的顺序对内存消耗很重要。
以下面的结构为例：
上述函数的输出为 96（字节），而所有字段相加为 82 字节。额外的 14 个字节来自哪里？
现代 64 位 CPU 以 64 位（8 字节）块的形式获取数据。如果我们有一个较旧的 32 位 CPU，它将执行 32 位（4 字节）的块。
IsDraftTitleIDIsDeletedIsDraftIsDeleted在 64 位架构上占用 <8 字节的 Go 类型：
- bool：1 个字节
- int8/uint8：1 个字节
- int16/uint16：2 个字节
- int32/uint32/rune：4 字节
- float32：4 字节
- byte：1个字节
无需手动检查结构并按大小对其进行排序，而是使用 linter 找到这些结构并（用于）报告“正确”排序。
- maligned: 不推荐使用的 linter，用于报告未对齐的结构并打印出正确排序的字段。它在一年前被弃用，但您仍然可以安装旧版本并使用它。
- govet/fieldalignment: 作为 gotools 和 govet linter 的一部分，fieldalignment 打印出未对齐的结构和结构的当前/理想大小。
要安装和运行 fieldalignment：
在上面的代码中使用 govet/fieldalignment：
使用 map[string]struct{} 而不是 map[string]bool
map[string]bool{}struct{}我不建议这样做，除非您的 map/set 包含大量值并且您需要获得额外的内存或者您正在为低内存平台进行开发。
使用 100 000 000 次写入地图的极端示例：
得到以下结果，在整个运行过程中非常一致：
使用这些数字，我们可以得出结论，使用空结构映射的写入速度提高了 3.2%，分配的内存减少了 10%。
map[type]struct{}map[type]bool然而，可读性大多数时候比（可忽略的）内存改进更重要。与空结构体相比，使用布尔值更容易掌握查找：