_alignof 返回类型所需自然对齐字节数，非 sizeof；它决定缓存行命中、simd 加载等硬件效率，受最严格成员或 alignas 影响，需配合 aligned_alloc 等确保运行时对齐，且字段顺序与 pragma pack 使用须谨慎。
用 _alignof 查结构体实际对齐值，别信 sizeof 就够了
_alignof 返回的是类型在内存中自然对齐所需的字节数，不是大小，也不是编译器“想给”的值。比如 struct { char a; double b; } 的 _alignof 很可能是 8（取决于 double 对齐要求），但 sizeof 可能是 16 —— 中间那 7 字节填充就是对齐开销的直接体现。
常见错误：把 sizeof(T) 当作对齐开销指标。错。真正影响缓存行命中、DMA 传输、SIMD 加载效率的是 _alignof(T) 是否匹配硬件约束（如 AVX2 要求 32 字节对齐）。
- 在 GCC/Clang/MSVC 中都支持
_alignof（C++11 起标准写法是alignof，但_alignof在旧代码或宏里仍常见） - 对未命名位域、空基类、
[[no_unique_address]]成员，_alignof不会变小 —— 它只看最严格成员的对齐需求 - 若结构体含
std::max_align_t或自定义alignas(64)成员，_alignof会跃升到对应值，哪怕其他字段都很小
看懂 struct 布局：用 #pragma pack 强制压缩 ≠ 消除对齐开销
加 #pragma pack(1) 确实能让字段紧挨着排，sizeof 变小，但代价是：CPU 访问非对齐地址可能触发异常（ARMv7+ 默认禁用）、x86 上降速 2–3 倍、某些指令（如 movaps）直接报 EXCEPTION_DATATYPE_MISALIGNMENT。
真实场景中，压缩布局只适合序列化/网络传输这类“只读不计算”的内存块，绝不能用于频繁访问的热数据结构。
组合式C++代码评审方案，融合静态分析、AI推理、多轮迭代评审和C++专项检查，适用于PR审查、增量代码审查、全项目评审和代码质量评分，触发词包括review cpp、cpp代码评审、C++review、代码审查。
-
#pragma pack(n)中的n必须是 1、2、4、8、16（VC）或 2 的幂（GCC），且不能小于结构体内任一成员的_alignof—— 否则编译器静默忽略 - 结构体嵌套时，外层
#pragma pack不自动传递给内层 struct；必须显式重申或用push/pop配对 - 用
offsetof(T, member)验证字段偏移，比肉眼算更可靠；注意它返回size_t，不是int
检测运行时对齐是否达标：用 reinterpret_cast<uintptr_t>(ptr) % alignof(T)</uintptr_t>
分配出来的指针未必满足你期望的对齐。堆上 new T 只保证 __STDCPP_DEFAULT_NEW_ALIGNMENT__（通常 16 字节），远不够 AVX-512 场景。所以关键对象得用 aligned_alloc 或 _mm_malloc。
验证方法很简单：
if (reinterpret_cast<uintptr_t>(ptr) % alignof(MyStruct) != 0) {
// 实际没对齐，后续 SIMD load/store 会崩
}</uintptr_t>
-
std::allocator的allocate()不保证高对齐，除非特化或传入std::align_val_t（C++17） - 用
std::vector存放alignas(32) struct类型时，其内部缓冲区不一定对齐到 32 —— 要自己用std::pmr::polymorphic_allocator配合std::pmr::synchronized_pool_resource控制 - 静态变量和栈变量默认按最大成员对齐，但函数内
alignas(64) char buf[1024]才真能拿到 64 字节对齐栈空间
对齐开销的隐藏成本：false sharing 和 cache line split
两个高频修改的字段如果落在同一 cache line（通常是 64 字节），即使各自对齐，也会因 CPU 核间缓存同步导致性能暴跌 —— 这不是 _alignof 能反映的，但属于对齐设计的延伸问题。
更隐蔽的是 cache line split：一个 16 字节的 __m128i 若起始地址是 63，就会横跨两个 cache line，一次 load 触发两次总线事务。
- 用
__builtin_assume_aligned(ptr, N)（GCC/Clang）或__assume_aligned（MSVC）帮编译器生成更优指令，但前提是 runtime 确实对齐，否则 UB - 结构体字段顺序很重要：把高频访问字段放前面，低频/只读字段放后面，减少 padding 被“夹在中间”的概率
- 对齐不是越大越好：
alignas(256)可能让结构体在数组中浪费大量空间，尤其当数组长度大而单个实例小的时候
alignof 数值背后，可能藏着缓存失效、指令异常、甚至跨平台 ABI 不兼容。动手前先问一句：这个对齐，是为硬件特性服务，还是为某种序列化协议妥协？答案不同，方案就完全不同。C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
