alignas用于显式指定数组或变量的首地址对齐要求，必须为2的幂且不小于元素自然对齐值；它仅约束起始地址，不影响元素大小与内部布局，常用于SIMD优化、动态对齐分配及结构体成员精细控制。
用 alignas 声明数组类型或变量
直接在数组声明前加 alignas(N)，是最常用且标准的方式。它告诉编译器该数组的首地址必须按 N 字节对齐（N 通常是 2 的幂，如 16、32、64）。注意：对齐值不能小于元素类型的自然对齐要求，也不能违反硬件限制（比如 x86-64 上最大通常为 64）。
常见错误是写成 alignas(32) int arr[10]; 却没检查 int 在当前平台是否允许被提升到 32 字节对齐——其实可以，但编译器只保证首地址对齐，不改变每个 int 元素的大小或内部布局。
-
alignas(16) double arr[4];—— 确保arr起始地址是 16 字节对齐，适合传给 AVX 指令 - 对齐值必须是常量表达式，不能是变量或运行时值
- 如果同时用
alignas和__attribute__((aligned(N)))（GCC/Clang），后者可能被忽略或触发警告
用 std::aligned_storage_t 手动管理对齐内存（C++11~C++20）
当需要动态分配或延迟构造、又必须控制对齐时，std::aligned_storage_t 是更底层的选择。它不存储对象，只提供一块满足对齐和大小要求的原始内存。
典型场景：实现自定义容器、对象池，或绕过栈/堆默认对齐限制。但它不自动构造/析构元素，必须配合 std::construct_at 和 std::destroy_at（C++20）或 placement-new / std::destroy（C++17）。
立即学习“C++免费学习笔记（深入）”；
-
alignas(32) std::aligned_storage_t<sizeof> storage;</sizeof>—— 得到 100 个float大小、32 字节对齐的裸内存 - 用
reinterpret_cast<float>(storage)</float>访问前，必须先调用std::construct_at构造对象 - C++23 已弃用
std::aligned_storage_t，新项目优先考虑std::aligned_alloc或std::pmr::polymorphic_allocator
用 std::aligned_alloc 分配堆上对齐数组（C++17 起）
需要运行时确定大小、又要求严格对齐（如 SIMD 处理大量浮点数据）时，std::aligned_alloc 是最稳妥的堆分配方案。它返回的指针满足指定对齐，且可直接用 operator delete[]（需搭配 std::free）。
关键限制：分配大小必须是 alignment 的整数倍；alignment 必须是 2 的幂且 ≥ alignof(std::max_align_t)（通常是 16）。否则行为未定义。
-
float* p = static_cast<float>(std::aligned_alloc(32, 100 * sizeof(float)));</float>—— 分配 100 个float、32 字节对齐 - 必须用
std::free(p)释放，不能用delete[]（除非重载了全局operator delete[](void*, std::align_val_t)） - Windows 上
_aligned_malloc/_aligned_free是等效替代，但非标准
结构体嵌套数组时的对齐陷阱
把对齐数组放进 struct 里，容易误以为整个 struct 自动获得高对齐。实际上，struct 的对齐由其最大对齐成员决定，但数组本身若未显式标注 alignas，仍按元素类型对齐。
例如：struct S { double arr[4]; }; 中 arr 首地址只保证 alignof(double)（通常是 8），哪怕你希望它用于 AVX2 指令——此时必须写成 alignas(32) double arr[4];，否则 struct 整体对齐不会因此提升，访问时仍可能触发对齐异常（尤其在 ARM64 或开启严格对齐检查时）。
- 结构体中多个
alignas成员会推高整个 struct 的对齐，也可能导致意外填充增大体积 - 用
static_assert(alignof(S) >= 32, "");显式验证，比靠经验更可靠 - Clang/GCC 加
-Wpadded可提示因对齐产生的填充，帮助发现隐式浪费
真正麻烦的不是怎么写对齐语法，而是搞清「谁在用这块内存」：是 CPU 指令直读？GPU 映射？还是跨线程共享？不同场景下，对齐要求、生效层级（变量级 / 分配器级 / 缓存行级）和验证方式都不同。漏掉任一环，代码可能在开发机跑得通，上线后在某款 CPU 上崩得无声无息。
