alignas不能让std::unique_ptr管理的对象自动对齐，仅影响编译期布局；需配合aligned_alloc和自定义删除器实现对齐内存的智能指针封装。
直接说结论：alignas 不能让 std::unique_ptr 管理的对象自动对齐，它只影响变量声明时的编译期布局；真正要实现对齐内存的智能指针封装，必须配合 aligned_alloc（或 _mm_malloc）和自定义删除器，alignas 仅在类型定义或栈变量中起作用。
为什么 alignas 加在类上对 new 出来的对象无效
alignas 是编译期指令，它不参与运行时内存分配逻辑。即使你写 struct alignas(64) Vec4 { float x,y,z,w; };，再执行 auto p = new Vec4[100];，p 的地址仍由 operator new 决定——而标准 new 只保证 alignof(std::max_align_t)（通常是 16 字节）对齐。
- 错误认知：以为加了
alignas(64)就能用_mm256_load_ps安全加载 - 真实结果：大概率触发
SIGBUS或std::bad_alloc（尤其在 ARM 或严格对齐平台） - 验证方法：打印
reinterpret_cast<uintptr_t>(p) % 64</uintptr_t>，几乎总是非零
std::unique_ptr 配合对齐内存的三步实操
标准 std::unique_ptr 默认用 delete 释放，无法处理 aligned_alloc 分配的内存。封装的关键是把分配、对齐、构造、释放全部串起来。
- 第一步：用
aligned_alloc(alignment, size)分配（POSIX/C++17），或_mm_malloc(size, alignment)（Windows/Intel）；注意alignment必须是 2 的幂，且size必须是其整数倍 - 第二步：用
std::construct_at（C++20）或 placement-new 构造对象，不能直接 reinterpret_cast 后用 - 第三步：传入匹配的删除器，例如
std::unique_ptr<t void>{ptr, [](T* p) { _mm_free(p); }}</t>；删除器类型必须显式作为模板参数一部分，否则退化为delete
容易踩的坑：对齐值、释放方式、类型约束
很多崩溃不是因为代码写错，而是对齐链路上某一个环节没对齐——尤其是跨平台或升级编译器后。
立即学习“C++免费学习笔记（深入）”；
-
aligned_alloc(64, 100)会失败：因为 100 不是 64 的整数倍；正确写法是aligned_alloc(64, (100 + 63) & ~63)或直接向上取整 - 混用分配与释放函数：用
aligned_alloc分配却调_mm_free，或反过来，必然未定义行为 -
alignas(64)的类不能直接塞进std::vector：默认分配器不保证连续元素间满足该对齐，需重载std::vector的分配器，或改用std::pmr::vector配合对齐资源 - GCC 12+ 对含虚函数的高对齐类报错：需加
[[no_unique_address]]或改用聚合体（POD）结构
最常被忽略的一点：对齐不是“设了就生效”，它是一条链——从原始内存分配（aligned_alloc）、到指针偏移调整（std::align）、再到对象构造（placement-new）、最后到析构释放（匹配删除器），任一环断裂，alignas 就只是个无害的注释。
