cpu缓存行与未对齐访问会触发多次内存读取：现代cpu按64字节缓存行读内存，跨行的int需两次读取，延迟翻倍；armv7等架构可能抛bus error或陷入内核修复，开销极大。
CPU缓存行与未对齐访问会触发多次内存读取
现代CPU从内存读数据不是按字节，而是按缓存行（通常是64字节）。当一个 int（4字节）跨了两个缓存行边界（比如地址 0x1007～0x100A），CPU必须读两次缓存行才能凑齐它——这直接翻倍延迟。更糟的是，某些架构（如ARMv7、旧版MIPS）遇到未对齐访问会直接抛 Bus Error 或陷入内核做软件修复，开销极大。
对齐的本质，是让变量起始地址能被自身大小整除。比如 alignof(int) 通常是4，那它的地址必须是4的倍数；alignof(double) 在x86-64上通常是8，地址就得是8的倍数。
- 结构体成员默认按自身对齐要求自然排布，编译器会在中间插入填充字节（
padding）来满足对齐 -
#pragma pack(1)强制取消填充，但可能引发未对齐访问——只在和硬件/协议打交道时谨慎用 - 使用
alignas(16)可显式提升对齐，常见于SIMD向量（__m128）或DMA缓冲区
结构体总大小为什么总是最大对齐数的整数倍？
因为结构体作为数组元素时，第二个元素的起始地址 = 第一个元素地址 + sizeof(Struct)。如果这个大小不满足最大成员对齐要求，那么数组中第二个元素的首成员就会未对齐。
例如：一个含 char 和 double 的结构体，在x86-64上 double 要求8字节对齐，所以整个结构体大小会被补齐到8的倍数（哪怕实际只用了9字节，也会变成16）。
立即学习“C++免费学习笔记（深入）”；
- 用
offsetof(Struct, member)查看成员偏移，能直观看到编译器插了多少padding -
std::is_standard_layout_v<t></t>为true时，结构体内存布局才可预测，适合与C ABI交互 - 不要靠
sizeof猜结构体真实数据长度——用std::size配合std::array更安全
new/malloc 返回的指针为什么天然满足最严格对齐？
C++标准规定 operator new 至少满足 alignof(std::max_align_t)（通常为16），malloc 也类似。这是为了确保任何内置类型或用户自定义类型都能安全构造在其上。
但注意：如果你用 malloc 分配一块内存，然后 placement-new 构造一个需要更高对齐的类型（比如 alignas(32) struct Vec32），而 malloc 返回的地址不满足32字节对齐，就会 UB —— 此时得用 aligned_alloc(32, size) 或 std::aligned_alloc。
-
std::vector内部用的就是operator new，所以其元素天然对齐，无需额外处理 - 自定义分配器里若重载
allocate，必须保证返回地址满足请求的alignment参数 - Clang/GCC 的
-Wcast-align能警告把未对齐指针转成强对齐类型的危险转换
结构体嵌套时对齐怎么叠加？
嵌套结构体的对齐要求，取其所有直接/间接成员中最大的 alignof。比如 struct A { char c; double d; }; 对齐是8；struct B { int i; A a; }; 中 A 贡献8，int 贡献4，所以 B 对齐仍是8。
但填充位置取决于声明顺序：把大对齐成员放前面，能减少总填充；反过来可能导致更多浪费。这不是性能优化重点，但影响二进制兼容性。
- 用
static_assert(alignof(T) == N)在编译期锁定对齐，避免ABI意外变化 - JSON序列化库常忽略对齐，直接 memcpy 字段——一旦结构体有 padding，就可能把垃圾字节写出去
- 调试时用
gdb的p/x &s.a看地址末几位是否为0，快速验证是否对齐
真正容易被忽略的是：对齐规则在不同平台（x86 vs ARM64）、不同编译器（GCC vs MSVC）、甚至同一编译器不同版本间都可能有细微差异。只要涉及跨平台共享内存、网络协议解析、或 GPU/CPU 共享缓冲区，就必须显式控制对齐，不能依赖默认行为。
