struct成员变量不紧挨存放是因CPU访问未对齐地址可能触发异常或降速，编译器插入padding确保各成员起始地址为其alignof(T)整数倍，并使结构体总大小对齐至最大成员对齐值。
struct 成员变量为什么不是紧挨着存放的
因为 CPU 访问未对齐地址可能触发硬件异常（比如 ARM 上的 Alignment fault），或者显著降速（x86 虽可容忍但跨 cache line 读写会慢）。编译器自动插入 padding 字节，确保每个成员起始地址是其自身 alignof(T) 的整数倍。
例如：struct { char a; int b; }; 中，int 通常要求 4 字节对齐，所以 a 后面会插 3 字节 padding，使 b 从 offset 4 开始。
-
alignof(char)是 1，alignof(int)通常是 4（取决于平台和 ABI） - 结构体总大小也会被补齐到其最大对齐值的整数倍，方便数组连续存放
- 用
offsetof(struct, member)可查实际偏移，比手算可靠
如何查看 struct 实际内存布局
别靠猜，用编译器内置工具或标准库辅助验证。Clang/GCC 支持 -fdump-record-layouts，能输出带 offset、size、alignment 的完整分析；C++17 起还可直接用 std::is_standard_layout_v 判断是否满足 POD 布局规则。
示例命令：g++ -c -fdump-record-layouts example.cpp，生成 example.cpp.000t.dump，里面会有类似：
立即学习“C++免费学习笔记（深入）”；
*** Dumping AST Record Layout
0 | struct X
0 | char a
4 | int b
| [sizeof=8, align=4]- Windows MSVC 对应选项是
/d1reportAllClassLayout - 运行时可用
sizeof(T)、alignof(T)、offsetof(T, m)组合验证 - 注意：调试器显示的地址是运行时结果，不代表编译期布局逻辑
改变默认对齐方式的三种常见手段
强制修改对齐会影响二进制兼容性，只应在明确需要时使用，比如对接硬件寄存器或网络协议。
-
alignas(N)修饰成员或整个 struct：提升对齐要求，如alignas(16) int x; -
#pragma pack(N)（GCC/Clang/MSVC 都支持）：限制最大填充字节数，#pragma pack(1)完全禁用 padding（但可能引发性能或 crash） -
__attribute__((packed))（GCC/Clang）或__declspec(align(N))（MSVC）：更细粒度控制，但语义略有差异，跨平台慎用
⚠️ 注意：packed 不会改变成员自身的对齐需求，只是压制 padding 插入 —— 若某成员仍需 4 字节对齐，而你把它塞进 1 字节偏移，运行时读写该成员就可能崩。
为什么 struct A { char a; double b; }; 在 x86-64 上 sizeof 是 16 而不是 9
因为 double 的 alignof(double) 通常是 8，所以 b 必须从 offset 8 开始；a 占 1 字节，后面补 7 字节 padding；结构体总大小再向上对齐到 8 的倍数，得到 16。
如果把 double b 换成 char c[8]，虽然大小一样，但 c 的对齐要求只有 1，整个 struct 就变成 9 字节（再对齐到 1 → 还是 9）。
- 成员顺序直接影响 padding 量：大对齐成员尽量往前放，能减少空洞
- 不同 ABI（如 System V vs Microsoft x64）对
alignof(long double)等类型定义不同，影响布局 - 模板实例化或继承链中，基类末尾 padding 可能被派生类首成员“复用”，但不保证
实际项目里最容易忽略的是：跨模块传递 struct 时，若一个模块用 pack(1) 编译，另一个没用，链接不会报错，但内存访问会错位。这种 bug 往往只在特定数据上偶然触发，极难复现。
