结构体中数组的对齐由其元素类型决定，而非数组长度；std::array 对齐与原生数组相同，均取决于元素类型；跨平台对齐差异需通过字段重排、alignas 或静态断言规避。
结构体内部数组的对齐由其元素类型决定
数组本身不参与对齐计算，真正起作用的是它的元素类型。比如 struct { char a; int arr[3]; } 中，arr 的对齐要求和单个 int 完全一致（通常是 4 字节），编译器只看 int 的对齐值，而不是整个数组长度。
这意味着：即使数组很长，只要元素是 char，它在结构体里的对齐偏移就是 1；如果是 double，就按 double 的对齐值（通常 8）来对齐起始地址。
- 对齐值取自数组元素类型的
alignof(T)，不是sizeof(T[n]) - 数组首地址必须满足该对齐要求，但数组内部元素之间严格按
sizeof(T)紧密排列，无额外填充 - 结构体总大小仍需按最大成员对齐值向上补齐，这个“最大成员”可能是某个数组的元素类型，而非数组本身
单独定义的数组变量不受结构体内存布局影响
全局或栈上定义的普通数组（如 int buf[1024];）没有“前面字段”要对齐，它的地址只受分配方式约束：malloc 返回的内存保证最大基本类型的对齐（C++17 起至少 alignof(max_align_t)），而栈变量由编译器按当前函数帧对齐规则安排——通常与目标平台默认对齐一致（x86-64 下常见为 16 字节）。
所以你用 sizeof 算出的数组大小，就是连续占用的字节数，中间绝不会插填充字节；但它的起始地址是否能被 16 整除，取决于上下文，不是数组自己决定的。
立即学习“C++免费学习笔记（深入）”；
组合式C++代码评审方案，融合静态分析、AI推理、多轮迭代评审和C++专项检查，适用于PR审查、增量代码审查、全项目评审和代码质量评分，触发词包括review cpp、cpp代码评审、C++review、代码审查。
- 用
alignas(32) int buf[1024];可强制指定对齐边界 -
std::aligned_storage或std::aligned_alloc在需要特定对齐时更可控 - 不要假设栈上数组一定按 16 字节对齐——不同优化等级、不同变量顺序可能导致实际地址变化
std::array 的对齐行为和原生数组完全相同
std::array<T, N> 是个聚合类型，标准明确要求其内存布局等价于 T[N]。也就是说，alignof(std::array<double, 5>) 等于 alignof(double)，它的对象首地址也只需满足 double 的对齐要求。
这带来一个常见误判：有人以为 std::array 因为是类模板就有额外开销或不同对齐，其实没有。它只是加了一层封装，底层仍是纯数据块。
-
std::array成员函数（如data()）返回的指针，指向的就是紧挨着对象起始地址的数据首字节 - 若需更高对齐（如 AVX 指令要求 32 字节对齐），仍得靠
alignas显式声明变量 - 不能依赖
sizeof(std::array)推断对齐值——它可能等于N * sizeof(T)，但对齐值只看T
跨平台对齐差异最容易在结构体嵌套时暴露
ARM64 默认对齐更严格（例如 long long 要求 8 字节对齐，但某些旧 ABI 曾允许 4），而 x86-64 通常宽松些。当结构体里有数组且前后还有其他字段时，不同平台下填充位置和数量可能不同，导致 offsetof 结果不一致，序列化或 memcpy 直接传输结构体就会出错。
比如 struct { char tag; int arr[2]; short s; } 在某些编译器+平台组合下，arr 前可能补 3 字节，也可能不补——取决于 char 后是否已自然满足 int 对齐。
- 用
#pragma pack或__attribute__((packed))可禁用填充，但会牺牲性能，且可能触发未对齐访问异常（尤其 ARM） - 更安全的做法是手动重排字段：把大对齐需求的成员（含数组）放前面，小的放后面，减少填充
- 永远用
static_assert(alignof(T) == ...)和offsetof断言关键偏移，别信文档或经验
对齐不是玄学，但它藏在结构体布局、ABI 规则和硬件限制的夹缝里。最常翻车的地方，是以为“数组长度长=对齐要求高”，或者在没验证的前提下假设某平台下的偏移是固定的。
