位运算判断地址对齐的正确方法是：(reinterpret_cast(ptr) & (alignment - 1)) == 0，前提是alignment为2的幂，且需先将指针转为uintptr_t，空指针需业务层单独处理。
如何用位运算快速判断地址是否对齐
地址对齐的本质是检查低几位是否全为 0。比如 alignof(int) 通常是 4，那合法地址必须能被 4 整除，即二进制末两位为 0。直接用取模效率低，编译器也常优化为位与操作。
正确写法是：ptr & (alignment - 1) == 0，前提是 alignment 是 2 的幂（所有标准对齐值都满足）。注意：该式仅对指针的整数值有效，需先转为 uintptr_t。
- 错误示例：
reinterpret_cast<uintptr_t>(ptr) % 8 == 0</uintptr_t>—— 可能被编译器生成除法指令，性能差 - 危险操作：
ptr & 7硬编码 7 —— 对齐值变化时极易遗漏修改，不具可维护性 - 边界情况：若
ptr为nullptr，reinterpret_cast<uintptr_t>(nullptr)</uintptr_t>是 0，表达式仍成立，但语义上空指针不“指向对齐内存”，需业务层额外约定
alignas 在类成员布局中的实际影响
alignas 不改变成员声明顺序，但会强制插入填充字节，从而影响 sizeof 和字段偏移。它只对当前声明项生效，不会“传染”到后续成员。
例如：
立即学习“C++免费学习笔记（深入）”；
struct S {
char a;
alignas(16) int b; // b 必须从 16 字节边界开始
char c;
};在多数平台，offsetof(S, b) 为 16（不是 1），sizeof(S) 至少为 32 —— 因为 c 跟在 b 后，而 b 占 4 字节，但结构体总大小还需满足自身对齐要求（此处由 alignas(16) 推高）。
- 常见误判：
alignas(32)加在第一个char上，会导致整个 struct 的sizeof变成 32，即使其他成员加起来才 5 字节 - 嵌套结构中，父 struct 的
alignas不覆盖子 struct 内部已有的对齐约束 - Clang/GCC 对
alignas小于自然对齐（如alignas(1) double）通常静默降级，但行为未标准化，应避免
动态分配对齐内存时 malloc vs. aligned_alloc 的选择
POSIX memalign 已废弃；C11 aligned_alloc 是首选，但它要求 size 是 alignment 的整数倍，否则行为未定义 —— 这点极易被忽略。
例如申请 100 字节、按 32 字节对齐的内存：aligned_alloc(32, 128) 合法，aligned_alloc(32, 100) 是 UB。
- Windows 下必须用
_aligned_malloc+_aligned_free，不能混用free - 若需跨平台且 size 不确定，建议封装一层：向上取整到 alignment 倍数，再调用
aligned_alloc - 使用
std::allocator自定义对齐时，C++17 起支持std::aligned_alloc，但需确保分配器的allocate方法显式处理对齐参数，否则可能退化为普通malloc
alignas 与模板推导冲突的典型场景
当模板函数接受一个 alignas(N) T* 指针时，N 不参与类型推导 —— alignas 是声明说明符，不是类型的一部分。所以 foo(ptr) 中，ptr 类型仍是 T*，对齐信息丢失。
这意味着你无法靠模板参数自动提取对齐值，也不能靠 decltype 拿到 alignas 属性。
- 可行方案：用
std::assume_aligned<n>(ptr)</n>（C++20）向编译器传递提示，但不改变类型 - 更稳妥的做法是显式传入对齐值作为非类型模板参数，例如
template<:size_t align> void process(char* p)</:size_t> - 静态断言常用组合：
static_assert(alignof(decltype(*ptr)) >= N, "ptr not aligned enough")，但注意这检查的是 *ptr 的类型对齐，不是 ptr 地址本身是否对齐
对齐判定和 alignas 处理真正棘手的地方在于：它横跨编译期类型系统、运行期地址计算、ABI 规则三者交界，任一环节假设错位，问题就藏得深且难复现。
