Go结构体大小不等于字段字节数之和，因编译器按内存对齐规则插入padding；字段顺序影响padding量，大字段前置可减少填充；涉及cgo等场景需显式同步对齐策略。
Go 结构体大小不等于字段字节数之和
直接结论：unsafe.sizeof 返回的结构体大小，往往比你手算的字段字节数总和大得多。这不是 bug，是 go 编译器按内存对齐规则主动插入 padding 的结果。比如 type st1 { a byte; b int64; c byte }，字段加起来才 10 字节，但 unsafe.sizeof(st1{}) 在 64 位系统下返回 24 —— 中间插了 14 字节填充。
字段顺序直接影响 padding 总量
结构体字段声明顺序不是语法装饰，它决定编译器如何排布内存。对齐规则要求每个字段起始地址必须是自身 unsafe.Alignof 值的整数倍。一旦前面字段结束位置不满足该条件，就得跳过若干字节（即 padding）再放下一个字段。
-
int64对齐值为 8，若前一字段结束在地址 9，它就必须从 16 开始 -
bool或byte对齐值为 1，可紧接上一字段之后存放 - 结构体总大小必须是所有字段中最大对齐值的倍数（如含
int64就得是 8 的倍数）
所以把大字段（int64、float64）往前放，小字段（bool、byte、int16）往后挤，能显著压缩 padding。例如：
type Bad { a bool; b int64; c bool } // 占 24 字节（a 后填 7 字节对齐 b，c 后再补 7 字节凑够 24）
type Good { b int64; a bool; c bool } // 占 16 字节（b 占 0–7，a 在 8，c 在 9，末尾补 6 字节到 16）
不验证就重排字段，可能踩 cgo 或 mmap 的坑
字段重排只对纯 Go 场景安全。一旦涉及 C 互操作（cgo）、内存映射文件（mmap）或序列化协议（如 protobuf），结构体布局必须与外部定义严格一致。C 端用了 #pragma pack(1) 或 GCC 属性强制紧凑对齐，而 Go 默认不匹配，就会读写越界或解析错位。
- 不要依赖字段顺序“碰巧一致”，必须显式同步对齐策略
- 用
unsafe.Offsetof或reflect.StructField.Offset校验字段偏移是否符合预期 - 必要时用
_ uint32等占位字段手动补齐，或借助// #include <stdalign.h>控制对齐
空 struct{} 也参与对齐计算
struct{} 自身大小为 0（unsafe.Sizeof(struct{}{}) == 0），但它在结构体中仍会影响后续字段的起始位置。如果它前面字段结束在奇数地址，后面字段仍要按自己对齐值向上取整——这个细节常被忽略，却会导致 padding 意外增加。
真正关键的不是“要不要对齐”，而是“对齐规则如何被触发”。只要结构体里有任意一个字段对齐值大于 1（比如 int16 起步就是 2），padding 就必然存在；而它的总量，完全由字段顺序、平台位宽、嵌套结构的最大对齐值共同决定。
