sizeof(struct)返回的不是真实内存占用，而是包含对齐填充的分配单位大小；成员顺序影响结果因编译器按声明顺序插入必要padding以满足各成员对齐要求。
sizeof(struct) 返回的到底是不是真实内存占用？
不是。sizeof 返回的是该结构体类型在当前编译器和对齐规则下的“分配单位大小”，它包含因内存对齐插入的填充字节（padding），但不反映运行时动态分配或指针所指内容的大小。比如一个只含两个 char 成员的 struct，sizeof 可能返回 4（因对齐到 int 边界），而非 2。
为什么成员顺序影响 sizeof 结果？
结构体按声明顺序逐个布局，编译器在每个成员前插入必要 padding 以满足其对齐要求。把宽成员（如 double、long long）放前面，窄成员（如 char、short）集中放后面，能显著减少填充。例如：
struct A { char a; double b; char c; }; // 常见错误顺序 → sizeof 可能为 24
struct B { double b; char a; char c; }; // 优化后 → sizeof 通常为 16（x64）
-
double对齐要求通常是 8 字节，struct A中a占 1 字节，接着要 pad 7 字节才能放b；b后c占 1 字节，再 pad 7 字节对齐整个 struct -
struct B先放b（8 字节），再连续放两个char（共 2 字节），末尾 pad 6 字节使总大小为 16（8 的倍数） - 不同平台（x86 vs x64）、不同编译器（GCC/Clang/MSVC）默认对齐策略可能不同，
#pragma pack或alignas会显式覆盖
如何查看实际内存布局和 padding 位置？
靠猜容易出错，用编译器内置工具或标准方法验证：
- 用
offsetof宏（#include <cstddef></cstddef>）检查每个成员偏移：offsetof(MyStruct, member) - GCC/Clang 加
-fdump-lang-rtl或使用godbolt.org查看汇编前的 RTL 输出 - MSVC 用
/d1reportAllClassLayout编译选项输出详细布局 - 简单调试法：定义 struct 实例，用
printf("%p", (void*)&s.member)打印各成员地址差值
注意：offsetof 在标准 C++ 中仅对标准布局类型（POD-like）可靠；含虚函数、非public 非static 成员、继承关系的 struct 不适用。
跨平台或序列化时怎么处理对齐差异？
直接 memcpy struct 到文件或网络流，很可能在另一端读错——因为目标平台的对齐规则、字节序、甚至 int 大小都可能不同。
- 不要依赖
sizeof(MyStruct)作为序列化长度 - 禁用对齐（如
#pragma pack(1)）可消除 padding，但会降低访问性能，且需两端一致启用 - 更安全的做法是手动序列化：逐字段读写，用固定宽度类型（
int32_t、uint8_t）并显式处理字节序 - 若用 Protocol Buffers、FlatBuffers 等序列化框架，它们已封装这些细节，无需手算内存布局
真正麻烦的不是算不准，而是误以为“算准了就能直接 memcpy”。对齐是编译期行为，而序列化是运行期数据交换——这两件事看起来像，本质完全不同。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
