深度剖析 Go 内存对齐：为什么你的结构体顺序决定了 VPS 的稳定性？

对于在 BuyVM 或廉价节点（如 512MB 内存）上跑自建服务的开发者来说，内存利用率就是生命线。在 .NET 中，CLR 会在运行时自动优化字段布局，但在 Go 中，字段定义的顺序决定了物理内存的消耗。

1. 为什么会产生空洞（Padding）？

现代 CPU 访问内存时并非按字节读取，而是按“字（Word）”读取。为了保证性能，编译器会进行内存对齐。

// 结构体 A
type BadOrder struct {
    A bool   // 1 byte
    B int64  // 8 bytes
    C bool   // 1 byte
} // 占用 24 字节！

在 BadOrder 中，为了让 B 对齐到 8 字节边界，A 之后会被填充 7 个字节。同理，C 之后也会填充 7 个字节。

2. 优化：从小到大还是从大到小？

黄金法则：将相同类型的字段放一起，并尽量按长度降序排列。

type GoodOrder struct {
    B int64  // 8 bytes
    A bool   // 1 byte
    C bool   // 1 byte
} // 仅占用 16 字节

实战意义：如果你在开发一个网络代理（如 Reality 实现），需要维护 10 万个活跃连接的状态（Status 结构体），通过简单的字段重排，你就能在不损失任何功能的情况下，节省出几十兆的物理内存，避免 VPS 因为 OOM (Out of Memory) 而崩溃。