alignof 是编译期运算符，返回类型对齐字节数；alignas 用于指定变量或类型的对齐方式，值须为2的幂且不超平台最大对齐。
alignof 用来查类型对齐要求，不是运行时函数
alignof 是编译期运算符，返回 std::size_t 类型的常量表达式，表示某类型在当前平台上的自然对齐字节数。它不接受变量，只接受类型名（或带括号的类型名）。
常见错误是写成 alignof(x)（x 是变量），这会编译失败；正确写法是 alignof(decltype(x)) 或直接 alignof(MyStruct)。
-
alignof(int)通常是 4（x86_64 下可能是 4 或 16，取决于 ABI 和编译器选项） -
alignof(std::max_align_t)给出平台“默认最大对齐”，常见值为 16（x86_64 GCC/Clang） - 结构体的
alignof取决于其最大成员对齐和填充，不是成员对齐之和
alignas 指定变量或类型的对齐方式，必须是 2 的幂且 ≤ 实现支持上限
alignas 可用于变量定义、类/结构体声明、联合体、位域（有限制），但不能用于函数参数、返回类型或 typedef 别名本身。
它的值必须是 2 的整数次幂（如 1、2、4、8、16…），且不能超过编译器支持的最大对齐（通常由 __STDCPP_DEFAULT_NEW_ALIGNMENT__ 或 alignof(std::max_align_t) 提示，超限会报错 error: requested alignment is larger than maximum supported）。
立即学习“C++免费学习笔记（深入）”；
- 对变量：
alignas(32) char buffer[256];—— 强制该数组首地址 32 字节对齐 - 对结构体：
struct alignas(64) CacheLine { int a; double b; };—— 整个对象按 64 字节对齐，sizeof(CacheLine)可能因填充变大 - 嵌套使用无效：
alignas(16) struct { alignas(32) int x; };中内层alignas被忽略（成员对齐不能超过所在类型对齐）
alignas 对结构体的影响不止于首地址，还改变 sizeof 和成员偏移
给结构体加 alignas(N) 不仅让对象起始地址满足 N 字节对齐，还会强制整个 sizeof 是 N 的倍数，并可能扩大成员间填充，以保证每个实例在数组中仍满足对齐。
组合式C++代码评审方案，融合静态分析、AI推理、多轮迭代评审和C++专项检查，适用于PR审查、增量代码审查、全项目评审和代码质量评分，触发词包括review cpp、cpp代码评审、C++review、代码审查。
例如：
struct Foo { char a; double b; }; // alignof=8, sizeof=16
struct alignas(32) Bar { char a; double b; }; // alignof=32, sizeof=32
此时 Bar arr[2] 中 arr[1] 地址仍是 32 字节对齐，但空间利用率下降——这是显式对齐的典型代价。
- 若结构体已有更大自然对齐（如含
__m256成员），再加alignas(32)可能无实际效果 - 用
alignas做缓存行对齐（如 64）时，注意结构体自身大小是否接近 64；否则容易浪费大量空间 - 跨编译单元使用
alignas类型时，确保所有地方看到一致定义，否则 ODR 违反风险高
对齐调试：用 offsetof + alignof 验证布局，别信直觉
结构体对齐行为受编译器、ABI、打包指令（#pragma pack）、成员顺序多重影响，靠“数字段”推断偏移极易出错。
验证手段只有两个可靠来源：标准库宏 offsetof 和 alignof，配合 sizeof 手动检查。
- 写个小测试：
static_assert(offsetof(MyType, member) % alignof(MyType) == 0); - 注意
offsetof对静态成员、引用、非 POD 类型未定义，只适用于标准布局类型 - Clang/GCC 支持
__builtin_offsetof更宽泛，但可移植性差；优先走标准offsetof
真正难的不是写 alignas，而是判断「这里到底需不需要对齐」以及「对齐后内存开销是否值得」——这两个问题没法靠语法解决，得看 profiling 数据和硬件特性。
