Go结构体字段顺序影响内存占用，需按对齐要求分组重排（8/4/2/1字节），避免填充浪费；嵌套结构体和序列化契约限制调整空间；缓存行对齐比单纯减小Sizeof更重要。
Go 结构体字段顺序直接影响内存占用，不调整就上线，可能多占 30%–50% 内存——尤其是高频创建的小结构体（如缓存项、HTTP 中间件上下文、数据库行映射），这种浪费会快速放大。
怎么一眼看出结构体有没有填充浪费
别猜，用 unsafe.Sizeof 和 unsafe.Offsetof 直接验证：
-
unsafe.Sizeof(YourStruct{})返回实际字节数；把所有字段类型大小加起来是“理论最小值”，差值就是填充总和 - 对每个字段
f，算unsafe.Offsetof(s.f)，再减去前一个字段结束位置（即Offsetof(prev) + Sizeof(prev)），差 > 0 就是填充 - 更省事：用
structlayout工具，它会明确标出gap: 7 bytes这类行
常见信号：Sizeof 明显大于字段大小之和（比如 24 字节结构体，字段加起来才 11）；int64 前面紧挨着 bool；结构体末尾多出 4 或 7 字节。
字段重排必须按对齐要求分组，不是简单按类型大小排序
对齐单位决定填充位置，不是字段本身占多少字节。例如 string 占 16 字节但对齐要求是 8，interface{} 同样对齐到 8；而 [3]uint16 整体对齐仍是 2，但长度影响总大小。
- 先放所有 8 字节对齐字段：
int64、uint64、float64、uintptr、指针、string、interface{} - 再放 4 字节对齐：
int32、uint32、float32、rune - 然后是 2 字节对齐：
int16、uint16 - 最后是 1 字节对齐：
byte、bool、int8、uint8
同组内顺序不关键；但跨组时，多个 bool 挨着放比单个 bool + 大字段 + bool 更省空间。
嵌套结构体和导出字段是容易被忽略的硬约束
嵌套结构体自身有对齐开销，不能只看内部字段。比如 struct{ a byte; b int64 } 单独就占 16 字节（1+7+8），你把它塞进外层结构体时，得把它当一个整体来对齐。
- 导出字段顺序若被 JSON、Gob、ORM（如 GORM、Ent）或反射依赖，改字段顺序可能导致序列化失败或字段映射错位
- 如果结构体用于 cgo，C ABI 要求严格匹配，字段顺序不能动
- CPU 缓存行（64 字节）比单个结构体对齐更重要：一个热点结构体若跨两个缓存行，频繁读写会触发伪共享，性能损失远超几字节填充
真正要优化的，从来不是“让 Sizeof 最小”，而是让热字段落在同一缓存行内、避免跨 cache line 访问、同时兼顾序列化契约——这三者冲突时，优先保后者。
