alignof 返回类型自然对齐所需的最小字节数，即该类型在内存中必须满足的对齐要求，一定是2的幂，与变量位置无关，仅由类型和abi决定。
alignof 返回的是什么，不是字节偏移而是对齐要求
alignof 返回的是类型在内存中**自然对齐所需的最小字节数**，比如 alignof(int) 通常是 4，alignof(double) 在多数平台是 8。它不表示变量实际在栈或堆上的地址偏移，也不受变量声明顺序影响——只取决于类型本身和编译器 ABI 规则。
常见错误：有人用 alignof 推算结构体内字段位置，结果出错。它不能告诉你 struct S { char a; int b; }; 里 b 的偏移是 4，只能说明 int 要求按 4 对齐，而实际偏移由结构体整体对齐规则决定。
- 对齐值一定是 2 的幂（1/2/4/8/16…），不可能是 3 或 6
- 空 struct（如
struct {};）的alignof是 1，但 sizeof 至少为 1 - 对用户定义类型，
alignof取其所有成员对齐值的最大值，再按alignas修饰调整
struct 默认对齐怎么算，别只看最大成员
结构体默认对齐值 = max(alignof(每个成员), alignof(嵌套 struct))，但**最终还要向上对齐到编译器默认的“基本对齐粒度”**（通常是 8 或 16，取决于目标平台和编译选项）。比如在 x86-64 Linux 上，即使结构体里全是 char，alignof(struct) 也可能是 8。
实际布局还受填充（padding）控制：每个成员从满足自身对齐要求的首个地址开始，编译器自动插入填充字节；结构体总大小会被补齐为自身对齐值的整数倍。
立即学习“C++免费学习笔记（深入）”；
- 启用
-Wpadded（Clang/GCC）能警告因对齐插入的 padding，帮你发现隐式浪费 -
__attribute__((packed))可禁用 padding，但会破坏对齐保证，访问未对齐地址在 ARM 或某些 x86 模式下直接触发硬件异常 - 成员顺序很重要：把大对齐成员放前面，小的放后面，通常能减少 padding（例如
double, int, char比char, int, double更紧凑）
alignas 怎么用才不翻车
alignas 是强制提升对齐要求的关键字，但它只能**扩大**、不能缩小对齐。比如 alignas(16) int x; 合法，但 alignas(1) double y; 无效（double 最小对齐是 8，1 不被接受）。
最常踩的坑是误以为 alignas 能让结构体变小——它只会让结构体更大或更严格。比如给一个本来对齐到 8 的 struct 加 alignas(32)，它的地址必须是 32 的倍数，sizeof 不变，但分配时可能多占一整块 cache line。
- 数值必须是 2 的幂，且不能超过实现限制（GCC 通常上限是 16384）
- 可用于变量、成员、类定义，但不能用于函数参数或返回类型
- 多个
alignas同时存在时，取最大值；与alignof冲突时，以alignas为准 - 动态分配需配对使用
aligned_alloc或std::aligned_alloc，普通malloc不保证高对齐
内存对齐影响性能的真实场景
对齐问题在 CPU 缓存、SIMD 和原子操作中会立刻暴露。比如用 __m256 读 32 字节数据，地址没按 32 对齐，x86 上可能降级成多条指令，ARMv8 则直接报 unaligned access fault。
另一个隐形杀手是 false sharing：两个高频更新的变量如果落在同一 cache line（通常 64 字节），即使逻辑无关，也会因缓存一致性协议反复同步，拖慢多线程性能。这时用 alignas(64) 拆开它们比加锁还管用。
- cache line 大小可用
std::hardware_destructive_interference_size（C++17）获取，但注意它只是建议值，非运行时保证 - 调试时用
objdump -d看汇编，检查是否生成了movaps（要求对齐）还是movups（不要求） - 结构体作为容器元素（如
std::vector<s></s>）时，对齐会影响整个数组起始地址和 stride，别只测单个对象
对齐不是越严越好，也不是可有可无的细节——它藏在结构体布局、分配器行为、CPU 指令语义的交界处，改一处可能牵动三处。尤其是跨平台或对接硬件驱动时，alignof 和 alignas 的行为差异比想象中更隐蔽。
