内存对齐是CPU硬性要求，未对齐访问在ARM/RISC-V上触发异常，x86虽兼容但降性能；结构体通过padding对齐，对齐值由最宽成员决定；alignas/alignof可主动控制但需防误用；跨平台序列化或mmap时对齐问题最易暴露。
内存对齐是 CPU 读写数据的硬性要求，不是 C++ 的“优化技巧”
它直接关系到程序能否正常运行——某些架构（如 ARM、RISC-V）遇到未对齐访问会触发 Bus Error 或 Alignment Fault；x86/x64 虽能容忍（自动拆成多次访问），但性能明显下降，且部分指令（如 _mm_load_si128）强制要求 16 字节对齐，否则崩溃。
结构体 sizeof 比成员总和大，是因为编译器在插 padding
对齐规则由最宽成员决定：结构体自身对齐值 = max(各成员的对齐值)；每个成员按自身对齐值偏移，不足时插入填充字节。
例如：
struct A {
char a; // offset 0, align 1
int b; // offset 4 (not 1), align 4 → pad 3 bytes
short c; // offset 8, align 2 → ok
}; // sizeof(A) == 12, not 7
-
int在偏移 1 处会导致未对齐（假设地址为 0x1001），CPU 取不到完整 4 字节 - 编译器把
b推到 0x1004，前面补 3 字节padding - 末尾可能还有填充（保证数组中第二个元素也对齐）
用 alignas 和 alignof 主动控制对齐，但要小心副作用
alignof(T) 返回类型 T 的自然对齐值（如 alignof(int) 通常是 4）；alignas(N) 强制指定对齐（N 必须是 2 的幂，且 ≥ 自然对齐值）。
立即学习“C++免费学习笔记（深入）”；
常见误用场景：
- 对
std::vector<char></char>用alignas(16)—— 容器内部缓冲区仍按char对齐，无效 - 给函数参数加
alignas(32)—— 参数传递不保证栈对齐，实际无意义 -
alignas(64) char buf[64]会让buf地址是 64 的倍数，但若它在栈上分配，取决于调用时的栈状态，不一定生效
跨平台序列化或 mmap 内存映射时，对齐问题会暴露得最彻底
比如从文件读取一个结构体到内存，或用 mmap 映射设备寄存器，如果结构体定义没考虑对齐，或者目标平台对齐要求不同（ARM64 默认 8 字节对齐，但某些外设要求 4 字节），就会出现字段错位、读出垃圾值甚至硬件异常。
稳妥做法：
- 用
#pragma pack(1)或__attribute__((packed))消除填充（但必须确保访问不违反硬件对齐约束） - 手动用
uint8_t数组 + 位移 +memcpy解包，绕过结构体对齐 - 检查
static_assert(alignof(MyStruct) == 4, "")，在编译期卡住不一致
真正难处理的不是“怎么对齐”，而是“哪里不能对齐却看起来能跑”——尤其在 x86 上开发后挪到 ARM 设备，一运行就崩，而且错误位置离真实问题很远。
