Go struct字段必须按unsafe.Alignof值降序排列才不浪费内存：int64/string/指针等对齐值8的放最前，int32/float32对齐值4居中，bool/int8对齐值1挤最后，嵌套struct按其最大对齐值参与排序。
struct字段顺序怎么排才不浪费内存
Go 不会自动重排 struct 字段顺序，所有 padding 都是你声明顺序的直接结果。错序一个 int8 和 int64，就可能让单个 struct 多占 7 字节——数组里每个元素都多这 7 字节，放大效应极明显。
- 按字段的
unsafe.Alignof值降序排列，不是按unsafe.Sizeof；int64、string、指针、interface{}对齐值都是 8，必须放最前 -
int32、float32对齐值是 4，集中放在中间 -
bool、int8、byte对齐值是 1，挤在最后，且要成组写（避免bool–int64–bool这种穿插） - 嵌套 struct 按它自身的最大对齐值参与排序，比如内嵌一个含
int64的 struct，它整体对齐值就是 8
怎么验证 struct 真实布局有没有坑
只看 unsafe.Sizeof 只知道总大小，看不出哪块被 pad 了；只看 unsafe.Offsetof 又没法判断字段之间是否留空。两者必须配合用。
- 检查字段间是否有 gap：
unsafe.Offsetof(s.b) - unsafe.Offsetof(s.a) > unsafe.Sizeof(s.a)→ 中间有 padding - 用
go install github.com/dominikh/go-tools/cmd/structlayout@latest，然后运行structlayout yourpkg YourStruct，输出里带gap [7]byte的行就是插了 7 字节的位置 - 别依赖
reflect.StructField.Offset—— 它和unsafe.Offsetof等价，但必须在定义该 struct 的包内调用才可靠
cgo 场景下对齐不一致会直接 panic
C 和 Go 默认对齐策略不同，尤其当 C 端用了 #pragma pack(1) 或 __attribute__((packed))，而 Go 端没适配，读写就会越界、随机 panic 或静默数据损坏。
- 不要依赖字段顺序“碰巧一致”——C 头文件改一行，Go 端就可能崩溃
- 显式同步方式：用
_ uint32手动补齐、调整字段顺序、或在 cgo 注释中引入// #include <stdalign.h> - struct{} 不省空间但可减堆分配，但它本身对齐值是 1，嵌入时不影响父 struct 对齐值
结构体总大小为什么总是 8 的倍数
struct 整体对齐值取所有字段对齐值的最大值，总大小必须是这个值的整数倍。比如含 int64 的 struct，整体对齐值就是 8，哪怕最后只剩 1 字节，也会补满到下一个 8 的倍数。
立即学习“go语言免费学习笔记（深入）”；
- 常见错误：以为
struct{a int8; b int64}占 9 字节，实际是 16 字节（b前补 7，末尾补 6） - 末尾 padding 是强制的，和字段间 padding 性质一样，只是容易被忽略
- 数组场景下，末尾 padding 会被每个元素重复，影响比单个 struct 更显著
字段顺序决定 padding 分布，而 padding 分布直接影响缓存行利用率和 GC 扫描开销——这不是“写完能跑就行”的细节，是高频对象（如数据库模型、网络包解析结构）上线后才发现的隐性瓶颈。
