结构体成员应按对齐要求从大到小排列以减少padding、提升缓存效率：先double/指针（8字节），再int/float（4字节），最后char/bool（1-2字节）；避免小类型打断大类型连续布局。
结构体成员顺序怎么排才不浪费 CPU 读取周期
CPU 从内存读数据时，一次拿 sizeof(size_t) 字节（通常是 4 或 8），如果一个 int 跨了两个 cache line，就得读两次。编译器不会帮你重排字段顺序——它只按你写的顺序放，再靠 padding 对齐。所以手动调整字段顺序，本质是减少 padding，让数据更紧凑、更贴合硬件的自然读取边界。
常见错误现象：sizeof(MyStruct) 比所有字段加起来大很多，尤其混用 char、int、double 时；结构体数组遍历时缓存命中率低，性能 profiling 显示 L1d_cache_miss 高。
- 把最大对齐要求的成员放最前：比如
double（通常 8 字节对齐）、long long、指针 - 接着放 4 字节对齐的，如
int、float、std::string* - 最后放 1 或 2 字节对齐的：
char、short、bool、std::byte - 避免在中间插小类型打断大类型连续布局，例如不要写
int a; char b; double c;，改成double c; int a; char b;
如何查清编译器实际加了多少 padding
光看代码猜对齐是危险的。offsetof 和 alignof 是唯一靠谱的 runtime 手段，而 #pragma pack 或 __attribute__((packed)) 只会掩盖问题，不解决访问效率。
使用场景：调试性能瓶颈、验证结构体布局是否符合预期、跨平台二进制协议设计。
立即学习“C++免费学习笔记（深入）”；
- 用
offsetof(MyStruct, field_name)查每个字段真实偏移 - 用
alignof(MyStruct)确认整个结构体的对齐要求（等于其最大成员的alignof） - 用
sizeof(MyStruct)减去字段大小总和，差值就是总 padding 字节数 - 别信 IDE 的“结构体预览”，它可能没开优化或用了不同 ABI；实测用
g++ -O2编译后跑offsetof
alignas 不是万能加速开关，乱用反而拖慢
alignas 强制提升对齐，但代价是内存占用暴涨、cache line 利用率下降。它真正有用的地方只有两类：SIMD 向量化（如 alignas(32) std::array<float></float>）、或对接硬件寄存器/ DMA 缓冲区。
容易踩的坑：alignas(64) 给一个只有 12 字节的结构体，导致每个实例占满一整条 cache line（64 字节），数组遍历时大量 cache 冲突；或者在堆上 new 时触发额外内存分配失败。
- 仅当明确需要满足特定硬件约束（如 AVX-512 要求 64 字节对齐）时才用
alignas - 优先靠字段重排 + 默认对齐达成目标，而不是强行拉高对齐
- 若必须用
alignas，检查alignof是否真被提升，有些旧编译器对模板内alignas处理不一致 - 堆分配时记得用
aligned_alloc或std::allocator特化，否则new可能不满足alignas
结构体嵌套时对齐会层层叠加
嵌套结构体不是简单拼接，外层结构体的对齐要求由其所有直接/间接成员中最大的 alignof 决定。一个 alignas(16) 的子结构体，会让包含它的父结构体也变成至少 16 字节对齐——哪怕父结构体其他字段全是 char。
性能影响：嵌套过深 + 对齐膨胀，会导致单个对象在内存中“占地”远超逻辑大小，L3 cache 容量迅速耗尽。
- 用
static_assert(alignof(Outer) == alignof(Inner), "")快速暴露意外对齐升级 - 如果只是想打包数据而非对接硬件，用
std::tuple或扁平化字段替代嵌套结构体 - 头文件里暴露结构体时，慎用
alignas在子结构体上——它会污染所有包含它的上层布局 - 考虑用
[[no_unique_address]]包裹零大小成员（如空基类），避免它们参与对齐计算
对齐不是越严越好，关键在匹配 CPU 一次访存宽度和 cache line 边界。多数时候，字段重排比加 alignas 更有效，也更安全。真正卡在内存带宽时，才值得为单个结构体抠那几个字节的 padding。
