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