8字节对齐是64位系统兼顾硬件兼容性与访问效率的平衡策略，源于cpu自然字长，避免跨缓存行访问且减少空间浪费；结构体成员降序排列、慎用紧凑对齐、显式指定对齐可优化布局。
8字节对齐不是硬性标准，而是64位系统下兼顾硬件兼容性与访问效率的常见默认策略。它用少量空间换稳定性能，在多数场景中利远大于弊。
为什么是8字节？不是4或16？
64位CPU的自然字长为8字节，一次总线事务可完整读取一个int64_t、指针或double——前提是它们起始地址是8的倍数。若强制4字节对齐，64位数据可能跨两个缓存行，触发两次内存访问；若盲目用16字节，则在大量小结构体中造成明显浪费。8字节是当前主流x86-64和ARM64平台的平衡点：满足所有基本类型（≤8字节）的对齐需求，又不过度牺牲密度。
对齐如何导致空间浪费？看真实布局
以典型结构体为例：
struct Record {
char flag; // 1字节 → 偏移0
int32_t id; // 4字节 → 需4字节对齐，但编译器按8字节对齐策略，会将其放在偏移8处
char tag; // 1字节 → 放在偏移12处
};
实际内存分布（64位系统）：
- flag 占偏移0–0，后接7字节填充（使下一个成员能落在8字节边界）
- id 从偏移8开始，占8–11
- tag 从偏移12开始，占12–12，再补3字节填充至16（结构体总大小需为8的倍数）
- 最终sizeof(struct Record) = 16，而理论最小仅6字节，浪费达62.5%
不对其齐的代价不只是“慢”
在不同平台上后果差异显著：
- x86-64：允许未对齐访问，但实测64位读写延迟增加约70%（如1.8 ns → 3.2 ns）
- ARM64（默认配置）：直接触发Alignment Fault，程序崩溃，除非显式启用非对齐支持（性能仍下降）
- 嵌入式RTOS或裸机环境：无异常处理机制，未对齐访问可能导致不可预测行为或静默数据损坏
怎么权衡？三条实用建议
- 结构体成员按类型大小**降序排列**：把int64_t、指针放前面，char/bool放后面，可减少填充间隙
- 对高频小对象（如链表节点、事件结构），用#pragma pack(1)禁用填充，但务必确保不涉及SIMD、原子操作或跨平台序列化
- 需要高性能且含大类型时，显式使用__attribute__((aligned(8)))或alignas(8)，比依赖默认更可控
