结构体成员应按类型大小降序排列以减少填充字节；合并相同对齐要求的成员连续存放；高频结构体可加alignas(64)对齐缓存行；需用offsetof、sizeof等实测验证优化效果。
核心思路很直接：把占用空间大的成员放前面，小的往后排，能显著减少编译器插入的填充字节。这不是玄学技巧，而是对齐规则自然推导出的结果。
按类型大小从大到小排列成员
结构体每个成员必须对其自身对齐值（通常是类型大小）的整数倍地址开始存放。如果小类型在前、大类型在后，中间大概率要补空字节才能满足大类型的对齐要求。
- 比如 int（4字节）→ char（1字节）→ short（2字节）：char 后需补3字节才能让 short 对齐到2字节边界，再补1字节让结构体总大小是4的倍数 → 总共浪费4字节
- 换成 int（4字节）→ short（2字节）→ char（1字节）：short 紧接 int 后（偏移4），对齐OK；char 紧接 short 后（偏移6），1字节无需额外对齐；最后补1字节使总大小为8 → 只浪费1字节
合并同对齐需求的成员，避免“夹心式”错位
连续放置对齐要求相同的变量，可消除它们之间的填充。尤其注意指针、long long、double 这类8字节类型，在64位系统中对齐值都是8，应尽量聚在一起。
- 错误示例：char a; double b; char c; double d; → a后补7字节对齐b，c后又要补7字节对齐d，结构体可能膨胀到40+字节
- 优化后：double b; double d; char a; char c; → 两个double连续占16字节，a和c紧随其后占2字节，最后补6字节对齐到16 → 总大小仅24字节
主动控制对齐边界，用 alignas 避免意外跨缓存行
即使成员排布合理，整个结构体大小仍可能不是64字节（典型CPU缓存行长度）的倍数。若该结构体数组被频繁访问，单次缓存加载可能只命中部分数据，造成额外延迟。
- 对高频使用的结构体，显式加 alignas(64)，确保每个实例起始地址都在新缓存行开头
- 配合成员重排后，若结构体自然大小是56字节，加 alignas(64) 会自动补8字节，但换来的是100%缓存行利用率
- 注意：不要滥用——alignas(64) 用于单个对象意义不大，真正价值在数组或内存池批量分配场景
验证是否生效，别靠猜
光靠手算容易出错，尤其嵌套结构体或多平台开发时。每次调整后务必实测：
- 用 offsetof 查每个成员真实偏移量
- 用 sizeof 和 alignof 确认结构体大小与对齐值
- 在关键循环里用 perf 或 VTune 观察 L1-dcache-load-misses 是否下降
- 对比重排前后相同数据量的处理耗时（图像处理、网络包解析等场景提升常达10%~25%）
