因为编译器插入填充字节以满足成员对齐要求，如char后跟int时补3字节使int地址为4的倍数；类对齐值取成员最大对齐值，可用-fdump-lang-class或/d1reportAllClassLayout查看实际布局。
为什么 sizeof 类的结果比成员加起来大？
因为编译器会在成员之间插入填充字节（padding），让每个成员的起始地址满足其对齐要求。这不是 bug，是硬件访问效率和 ABI 规范强制要求的行为。
比如 int 通常需 4 字节对齐，char 只需 1 字节对齐，但若 char 后紧跟 int，编译器会在 char 后补 3 字节空隙，确保 int 落在 4 的倍数地址上。
- 对齐值由类型决定：
alignof(int)通常是 4，alignof(double)在 x64 上常为 8 - 类整体对齐值取所有成员对齐值的最大值（再向上对齐到编译器默认边界，如 8 或 16）
- 填充只发生在成员之间或末尾，不会插在数组元素内部
怎么查某个类的实际内存布局？
用编译器提供的工具看，而不是靠手算。GCC/Clang 支持 -fdump-lang-class，MSVC 用 /d1reportAllClassLayout，输出里会明确标出 offset、size、padding。
更轻量的方法是写个简单测试：
立即学习“C++免费学习笔记（深入）”；
struct S { char a; int b; };
std::cout << "a at: " << offsetof(S, a) << ", b at: " << offsetof(S, b) << "\n";
std::cout << "sizeof(S): " << sizeof(S) << "\n";
输出可能是 a at: 0, b at: 4 和 sizeof(S): 8 —— 中间 3 字节就是 padding，末尾还有 1 字节对齐填充。
成员顺序怎么影响 sizeof？
顺序直接影响 padding 总量。把宽类型（如 double、long long）放前面，窄类型（char、bool）集中放后面，能显著减少填充。
- 坏顺序：
char a; double b; char c;→ 可能占 24 字节（a 占 1，pad 7，b 占 8，c 占 1，pad 7） - 好顺序：
double b; char a; char c;→ 通常 16 字节（b 占 8，a+c 占 2，pad 6 对齐到 16） - 结构体嵌套时，子结构体的对齐要求也会“传染”上来，别只盯着单层成员
什么时候对齐规则会被打破？
显式干预时：用 #pragma pack(n) 或 alignas 可以改变对齐行为，但代价是可能触发非对齐访问（在 ARM 或某些 x86 模式下直接 crash 或性能暴跌）。
-
#pragma pack(1)禁用所有 padding，sizeof等于成员原始大小之和，但int*指针可能指向非 4 倍数地址 -
alignas(16) struct X { ... };强制整个结构体按 16 字节对齐，即使它只有 3 个char - 网络协议或文件格式解析常用
pack，但仅限于明确控制二进制 layout 的场景，别滥用
对齐不是抽象概念，它刻在 CPU 指令集里。一个没注意的 char 插在中间，就可能让缓存行多加载一倍数据，或者让 memcpy 变慢几倍——这些细节不报错，但藏在性能毛刺和偶发崩溃背后。
