std::alignment_of::value 返回类型 t 在标准内存分配中要求的最小对齐字节数，即对象起始地址必须是该值的整数倍，不满足则构造对象为未定义行为。
std::alignment_of 返回什么值？
std::alignment_of<t>::value</t> 返回的是类型 T 在标准内存分配（如 new 或栈上）中要求的**最小对齐字节数**，即该类型对象起始地址必须是该数值的整数倍。它不依赖编译器扩展或平台 ABI 的“最大可能对齐”，而是由语言标准和当前编译环境共同决定的、实际生效的对齐约束。
常见误解是把它当成“推荐对齐”或“可选优化值”——其实它是硬性下限：若你手动分配内存（比如自定义内存池），而起始地址不满足 std::alignment_of<t>::value</t>，那么构造 T 对象就属于未定义行为（UB），哪怕代码看似跑通了。
- 对
int通常是4（x86/x64），但某些嵌入式平台可能是2 - 对
std::max_align_t是当前平台“最严格的基本类型对齐”，常为16（x64 上 SSE/AVX 对齐需求） - 对含
alignas(32)成员的结构体，std::alignment_of会反映该alignas，不是按成员推导出来的“自然对齐”
在内存池里怎么用 std::alignment_of 做地址对齐？
自定义内存池分配原始内存后，不能直接把指针强转成目标类型的指针——必须先确保该指针地址满足对齐要求。典型做法是：从原始块起始地址出发，向上找到第一个满足 std::alignment_of<t>::value</t> 的地址。
别手写模运算（容易溢出或逻辑错），用标准库的 std::align 函数更安全：
立即学习“C++免费学习笔记（深入）”；
void* raw = malloc(1024);
std::size_t space = 1024;
std::size_t alignment = std::alignment_of_v<MyType>;
void* aligned_ptr = nullptr;
if (std::align(alignment, sizeof(MyType), raw, space)) {
aligned_ptr = raw; // 此时 raw 已被调整为对齐地址
}-
std::align会修改传入的raw和space参数：前者变成对齐后的地址，后者变成剩余可用字节数 - 如果返回
false，说明剩余空间不足以容纳对齐后的对象（哪怕原始空间够大） - 不要对
aligned_ptr做算术运算再 reinterpret_cast——对齐只保证起点，后续偏移仍需自己检查
为什么不能只用 sizeof(T) 或 alignof(T) 宏？
alignof(T) 和 std::alignment_of_v<t></t> 等价，但很多人误以为只要对齐到 sizeof(T) 就够了——完全错误。例如 double 在多数平台是 8 字节大小，但对齐要求也是 8；而 struct { char a; double b; } 大小可能是 16（因填充），但它的对齐要求仍是 8，不是 16。
- 对齐要求由类型声明（含
alignas）、成员中最严格的对齐需求、以及 ABI 共同决定，和sizeof没有函数关系 - 用
sizeof(T)当对齐值，在含__m128或std::atomic<long long></long>的类型上大概率触发 SIGBUS 或静默数据损坏 - 宏
alignof是 C++11 起的运算符，std::alignment_of是其 traits 封装，二者结果一致；但前者不能用于非类型上下文（比如模板参数），后者可以
std::alignment_of 在泛型内存池中的坑
写一个支持任意类型的内存池模板时，很容易在构造函数或分配函数里漏掉对齐计算的泛化处理。最典型的错误是：把对齐值写死成 alignof(std::max_align_t)。
这会导致严重浪费——比如只存 int 的池子也按 16 字节对齐，空间利用率暴跌；更糟的是，某些平台（如 ARM64）对过度对齐有额外开销，甚至拒绝分配。
- 每个类型池应独立使用
std::alignment_of_v<t></t>计算，而不是统一用最大对齐 - 若池子要支持多种类型混存（如 arena allocator），则必须按所有可能类型的 **LCM（最小公倍数）** 对齐，而非最大值——但 LCM 可能爆炸（如对齐 3 和 5 得 15），此时应改用分桶策略
- 模板参数推导失败时（如
T是 cv-qualified 或引用），std::alignment_of_v<t></t>仍合法，但语义上是对去除修饰后的类型取对齐值
对齐不是“越严越好”，它是类型契约的一部分：满足它，才有定义良好的对象布局；违反它，编译器没义务报错，但运行时崩得毫无征兆。
