结构体字段应按对齐值降序排列（8→4→2→1）以减少填充字节，避免内存浪费和GC压力；需用unsafe.Offsetof或structlayout工具验证填充位置，注意嵌套结构体、序列化兼容性及缓存行对齐。
Go 结构体字段顺序直接决定内存占用大小，不优化可能多占 50% 内存；这不是微优化，而是影响 GC 压力和缓存命中率的硬指标。
为什么
返回值远大于字段字节和
因为 Go 编译器不会重排字段，只按声明顺序分配，并在必要位置插入填充字节（padding），确保每个字段起始地址满足其对齐要求。例如
要求 8 字节对齐，若前一个字段只占 1 字节（如
），编译器就在中间补 7 字节，让它能从地址 % 8 == 0 的位置开始。
结构体总大小还必须是其最大字段对齐值的整数倍，所以末尾也可能补空。
常见错误现象：
看似 1+8+4=13 字节，实际
返回 24
是 8，
是 4，
是 1
不要依赖“字段小就放前面”的直觉——小字段插在大字段中间，反而会触发成片填充
按对齐值降序排列字段：8 → 4 → 2 → 1
这是最有效、最易执行的策略。不是简单按类型大小排序，而是按对齐值分组，同一组内顺序不敏感，跨组时大对齐优先。
8 字节对齐：所有
/
/
/
、指针、
、
4 字节对齐：
/
/
/
2 字节对齐：
/
1 字节对齐：
/
/
/
多个
或
连续声明，比穿插在大字段间更省空间（避免单个
后跟
导致 7 字节填充）
用
和工具验证填充
别猜，实测。靠
只能看出总大小是否异常，真正定位“哪段被填了”得看偏移量或用工具。
手动验证：
就说明 A 和 B 之间有 padding
推荐工具：
，然后运行
输出中带
的行就是填充位置，例如
表示插了 7 字节
编译器提示也可辅助：
有时会打印字段布局摘要
容易被忽略的边界情况
字段重排只是起点，真实项目里几个约束常让优化失效甚至倒退：
嵌套结构体自身有对齐要求，比如
单独占 16 字节，不能只看内部字段加总
导出字段顺序若被 JSON、Gob、ORM（如 GORM）或反射依赖，改顺序可能破坏序列化行为
数组对齐按单个元素算，但长度影响总大小——别为了省 padding 把
拆成四个独立
字段，那会引入更多对齐开销
CPU 缓存行（通常 64 字节）比单个结构体对齐更重要：一个高频访问的结构体若跨两个缓存行，性能损失远超几字节 padding
unsafe.Sizeofint64booltype Bad { A bool; B int64; C int32 }unsafe.Sizeofunsafe.Alignof(int64(0))unsafe.Alignof(int32(0))unsafe.Alignof(bool(true))int64uint64float64uintptrstringinterface{}int32uint32float32runeint16uint16boolbyteint8uint8boolbyteboolint64unsafe.Offsetofunsafe.Sizeofunsafe.Offsetof(s.B) - unsafe.Offsetof(s.A) > unsafe.Sizeof(s.A)go install github.com/dominikh/go-tools/cmd/structlayout@lateststructlayout yourpkg YourStructgapgap [7]bytego tool compile -gcflags="-m -m" main.gostruct{ a byte; b int64 }[4]bytebyte