std::align 用于在给定缓冲区内查找满足对齐要求的子地址，它修改传入的指针和剩余空间参数而非返回新地址，使用时需传引用、检查输入有效性、确保 space ≥ alignment，并用 reinterpret_cast 检查对齐结果。
如何用 std::align 手动对齐内存块并验证对齐结果
直接调用 std::align 是最可控的底层对齐判定方式，它不分配内存，只在给定缓冲区内“滑动窗口”找满足对齐要求的子地址。关键在于：它修改传入的指针和剩余大小参数，不是返回新地址——这点极易误用。
常见错误现象：std::align 返回空指针却没检查输入 ptr 和 space 是否有效；或忽略它会改写 ptr 和 space 的值，导致后续逻辑错乱。
实操建议：
- 始终传入可修改的指针引用（
void*& ptr）和大小引用（size_t& space），否则对齐失败时你根本不知道哪一步被截断 - 对齐前先确保
space >= alignment，否则必然失败——std::align不补空间，只裁剪 - 对齐后用
reinterpret_cast<uintptr_t>(ptr) % alignment == 0</uintptr_t>再次验证，别只信返回值
示例片段：
立即学习“C++免费学习笔记（深入）”；
void* buf = malloc(1024);
void* ptr = buf;
size_t space = 1024;
if (std::align(16, 32, ptr, space)) {
// ptr 现在是 16 字节对齐、且至少有 32 字节可用的起始地址
assert(reinterpret_cast<uintptr_t>(ptr) % 16 == 0);
}
alignof 与 alignas 在类型定义阶段的实际约束力
alignof 查的是编译器为该类型默认选择的自然对齐值，但这个值可能被 alignas 覆盖——前提是覆盖值合法（≥自然对齐，且是 2 的幂）。问题在于：alignas 只影响变量/类型的**声明时布局**，对运行时指针无任何作用。
使用场景：结构体字段重排、SIMD 类型封装、与硬件寄存器交互时强制对齐。
容易踩的坑：
-
alignas(32) struct S { char a; };合法，但sizeof(S)变成 32 —— 编译器会在末尾填 31 字节，不是你想的“让a对齐到 32” -
alignas对new分配的单个对象生效，但对new T[10]数组，仅首元素保证对齐，其余元素按sizeof(T)紧邻排列，未必满足相同对齐 -
alignof(std::max_align_t)是平台最大标准对齐值（如 x64 下常为 16），但自定义对齐超过它需用aligned_alloc或operator new重载
为什么 aligned_alloc 失败时返回 nullptr 而不是抛异常
因为它是 C11 标准函数，C++17 将其引入但保留 C 风格语义：失败不抛异常，只设 errno（如 EINVAL 表示 alignment 非 2 的幂，ENOMEM 表示内存不足）。这和 new 的行为完全不同。
性能影响：相比 malloc，aligned_alloc 可能触发更复杂的页管理（尤其 alignment > 页大小时），在嵌入式或实时系统中要测实际延迟。
实操建议：
- 务必检查返回值是否为
nullptr，不要假设成功 - alignment 参数必须是 2 的幂且 ≥
sizeof(void*)，否则行为未定义 - 用完后必须用
free()释放，不能混用delete—— 它和malloc同源，不是new体系
现代 C++ 中避免手写对齐判定的三个可靠替代路径
除非你在写内存池、序列化框架或调试工具，否则真没必要反复手算地址模运算。标准库和编译器已提供更安全的抽象。
推荐路径：
- 优先用
std::vector+std::allocator_traits::allocate配合自定义 allocator，把对齐逻辑封装进分配器，上层完全无感 - 对单对象，用带对齐参数的
operator new(std::size_t, std::align_val_t)（C++17），它自动调用aligned_alloc或等效机制，失败时抛std::bad_alloc - 静态/栈上对齐：直接用
alignas声明变量，比运行时计算地址再std::align更高效也更清晰
真正难处理的是跨模块、跨 ABI 的对齐传递——比如 DLL 导出结构体，此时 alignas 值必须在所有编译单元中一致，且链接器不校验，只能靠构建时静态断言（static_assert(alignof(T) == 32, "...")）兜底。
