_alignof返回类型在当前平台的自然对齐边界（编译期常量，单位字节），与变量实际地址无关；它恒等于该类型的默认对齐值（如x86-64下_alignof(int)为4），不随结构体中偏移变化，且必须是2的幂，非标扩展下结果不可靠。
如何用 _alignof 验证变量真实对齐要求
_alignof 返回的是编译器为该类型指定的**自然对齐边界**（单位字节），不是运行时计算结果，也不受变量实际地址影响。它只和类型定义、ABI 及编译器设置有关。
常见误用是以为 _alignof(int) 会随 int 在结构体中的偏移而变化——其实不会。它恒等于该类型在当前平台下的默认对齐值（如 x86-64 下 _alignof(int) 通常是 4，_alignof(long long) 是 8）。
- 在结构体中验证：定义
struct S { char a; int b; };，_alignof(S::b)无意义（C++ 不支持成员类型对齐查询），但_alignof(int)仍是 4；整个S的对齐由_alignof(S)给出（通常为 4，因最大成员对齐是 4） - 注意宏冲突：
_alignof是 GCC/Clang 扩展，MSVC 用__alignof；C++11 起应优先用标准alignof运算符（返回std::size_t） - 对齐值一定是 2 的幂（0 除外），若出现非 2 幂结果，说明编译器启用了非标扩展（如
-fpack-struct），此时_alignof结果不可靠
用模运算判断某地址是否满足对齐要求
给定一个指针 p 和对齐值 A（必须是 2 的幂），判断其是否按 A 字节对齐，本质是检查低 log₂(A) 位是否全为 0。等价于：(uintptr_t)p % A == 0，但模运算有性能开销；更高效写法是：((uintptr_t)p & (A - 1)) == 0。
- 必须先转成整型：直接对指针做位运算未定义行为，务必用
uintptr_t（定义在 - 对齐值
A必须是 2 的幂，否则A - 1不能生成正确掩码；例如A = 16→ 掩码0xF，取低 4 位清零后判零 - 错误示例：
char* p = new char[100]; if (p % 8 == 0)—— 编译不通过（指针不能直接取模），且未转整型 - 正确示例：
char* p = new char[100]; uintptr_t addr = reinterpret_cast<uintptr_t>(p); if ((addr & (8 - 1)) == 0) { /* 8-byte aligned */ }</uintptr_t>
为什么 new 分配的内存不一定满足自定义对齐
普通 new 只保证满足 alignof(std::max_align_t)（通常为 16），无法满足更高对齐（如 32、64 或 AVX-512 所需的 64 字节）。强行用模运算判定可能“误报对齐”，但后续访问仍触发 bus error 或性能惩罚。
-
std::aligned_alloc（C++17）或_aligned_malloc（MSVC）才是安全选择；分配后仍建议用位运算校验：(reinterpret_cast(ptr) & (alignment - 1)) == 0 - 使用
alignas修饰变量仅影响**栈上或静态存储期对象**的布局，不影响堆分配行为 - 结构体字段对齐 ≠ 整体对齐：即使每个字段都 8 字节对齐，结构体自身对齐仍取决于最宽成员；但填充字节可能导致首地址不对齐（如结构体嵌套在数组中时）
实战中容易被忽略的对齐陷阱
对齐问题往往在跨平台或启用优化后才暴露，不是编译错误，而是运行时崩溃或静默数据损坏。
- memcpy/memset 传入未对齐指针：某些 ARM 架构或开启
-mstrict-align时会 SIGBUS；x86 通常容忍但慢几倍 - union 成员对齐取最大值，但若含
alignas(32) char buf[32]，整个 union 对齐变成 32，可能意外增大结构体体积 - 模板元编程中用
alignof(T)做 SFINAE 判定时，注意引用类型（T&）的alignof等于alignof(T)，而非 1 - 调试技巧：用
gdb查看地址：p/x $rdi（假设参数在rdi），再手动算& 0xF快速判断是否 16 字节对齐
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
