32位机器下结构体double成员的地址对齐填充逻辑疑问

这个约束本质是硬件架构和ABI规范共同作用的结果，核心原因有以下几点：

• 特殊硬件指令的兼容性要求
  很多32位处理器本身原生支持64位的加载/存储指令（比如x86的fld指令、ARM的ldrd指令），这类指令要求操作数必须从8字节对齐的地址开始读取，一旦地址不符合要求，要么直接触发硬件异常导致程序崩溃，要么需要额外多消耗数十个时钟周期处理对齐异常，性能损耗远高于两次普通内存加载的开销。就算当前编译的目标平台不使用这类指令，保持8字节对齐也能保证同一份结构体定义在32位、64位平台之间交互时内存布局完全一致，避免跨平台数据交换出现解析错误。
• 原子操作的底层要求
  不少业务场景需要对double类型做原子读写，只有当整个64位数据存放在8字节对齐的内存块中时，硬件才能保证64位数据操作的原子性。如果仅对齐到4字节，double的高32位和低32位可能分布在两个不同的缓存行甚至内存页中，就算分两次加载也没法保证两次读取的间隙数据不会被其他线程修改，根本无法实现合法的原子操作。
• 减少缓存层面的性能损耗
  你提到的两次加载即可读取是理想情况，但若double仅对齐到4字节，恰好跨了两个缓存行边界的话，CPU需要加载两个完整的缓存行才能拿到完整的double数据，不仅会额外占用缓存空间，还可能多触发一次缓存失效的开销。在连续读写大量double数组的场景下，8字节对齐的性能比仅4字节对齐要高出30%以上。
• ABI规范的强制约定
  几乎所有主流32位平台的ABI（应用程序二进制接口）都明确规定double类型的自然对齐长度为8字节，编译器会默认遵循这个规则生成代码。如果手动强制修改为4字节对齐，编译出的二进制文件将无法和系统库、第三方库正常交互，函数传参、结构体传递时会直接因为内存布局不匹配出现异常。

补充说明：如果是嵌入式等极端内存受限、且不需要和外部二进制交互的场景，可以通过编译器的packed属性手动关闭对齐规则压缩结构体体积，使用前需要确认对应的硬件不会触发对齐异常。

内容的提问来源于stack exchange，提问作者not_that_guy123