alignof获取类型对齐要求，数组对齐由元素类型决定，与长度无关；结构体中数组起始偏移受整体对齐影响；运行时实际地址对齐不可靠，需手动验证。
用 alignof 获取类型对齐要求
数组的内存对齐由其元素类型决定，不是数组本身独立决定的。所以直接对数组类型调用 alignof 就能拿到它在内存中必须满足的对齐边界（单位字节）。比如 alignof(int[10]) 和 alignof(int) 结果一样，因为数组类型不改变底层元素的对齐约束。
常见误区是以为数组长度会影响对齐——不会。无论 int[1] 还是 int[1024]，alignof 都返回 4（x86-64 下典型值）。
-
alignof(char[100])→ 返回1 -
alignof(double[3])→ 返回8（通常） -
alignof(std::string[5])→ 返回std::string自身的对齐值（通常是8或16，取决于标准库实现）
结构体内数组的对齐可能被“抬升”
当数组作为结构体成员时，它的起始地址受结构体整体对齐规则影响。编译器会按最大对齐成员向上对齐该字段偏移，但数组本身的对齐要求不变——只是它实际落下的地址可能比 alignof 值更大。
例如：
立即学习“C++免费学习笔记（深入）”；
struct S {
char c;
int arr[2]; // arr 起始偏移通常是 4，而非 1，因为结构体对齐到 int 的边界
};此时 offsetof(S, arr) 是 4，但 alignof(int[2]) 仍是 4。二者一致是巧合；若把 int 换成 std::max_align_t 数组，偏移可能变成 16，而 alignof 还是 16。
- 结构体总大小也受最后一个成员对齐影响：
sizeof(S)会向上补齐到alignof(S)的整数倍 - 用
#pragma pack(n)或[[alignas(N)]]可手动干预，但会破坏 ABI 兼容性
运行时无法直接查栈/堆上数组的实际对齐地址
alignof 给的是编译期承诺的最小对齐，不是运行时地址的真实对齐值。你拿到一个指针，比如 int* p = new int[100]，p 实际地址可能对齐到 16 字节甚至 32 字节，但这超出语言标准保证范围。
如果真需要检查某块内存是否满足特定对齐（比如给 AVX 指令用），得自己算：
bool is_aligned(const void* ptr, size_t alignment) {
return reinterpret_cast<uintptr_t>(ptr) % alignment == 0;
}- 对堆内存：
new保证至少alignof(max_align_t)（通常是16），但不保证更多 - 对栈变量：编译器通常按目标平台 ABI 对齐（如 x86-64 SysV 是
16字节），但不能依赖——尤其开启优化后可能重排或复用空间 - 想确保强对齐？用
aligned_alloc（C++17）或_aligned_malloc（MSVC）
模板里怎么泛化处理数组对齐
写模板函数时，别硬写 T[n]，而是用 std::array 或引用类型推导，让 alignof 自动作用于完整类型：
template<typename T, size_t N>
constexpr size_t get_array_alignment() {
return alignof(std::array<T, N>);
// 或者更直白：return alignof(T[N]);
}注意 std::array<t></t> 的对齐和 T[N] 完全一致，但它是个完整类型，方便在模板中传递和特化。
- 避免写
alignof(T)代替alignof(T[N])—— 虽然值一样，但语义不同；万一T是用户自定义类型且重载了对齐控制，行为可能不一致 - 如果模板参数是
T*或std::vector<t></t>，它们的对齐信息无意义——容器本身只管指针，数据在堆上，对齐由分配器决定
对齐不是“数组的属性”，而是“类型布局契约”的一部分。真正容易被忽略的，是结构体字段顺序和填充带来的偏移漂移——alignof 告诉你下限，但实际内存分布得靠 offsetof 和 sizeof 配合验证。
