结构体为成员分配独立内存，总大小为成员大小之和加填充；联合体所有成员共享同一内存，总大小等于最大成员大小。
C++的结构体（
struct）和联合体（
union）在内存分配和布局上的核心差异在于它们成员变量的存储方式：结构体为每个成员分配独立的内存空间，而联合体则让所有成员共享同一块内存区域。这意味着结构体的总大小通常是其成员大小之和（加上可能的填充），而联合体的总大小则等于其最大成员的大小。
当我初次接触C++的内存布局时，
struct和
union的设计哲学就让我觉得挺有意思，甚至有点像两种截然不同的思维模式。
struct，在我看来，更像一个严谨的包裹，每个物件（成员）都有自己专属的位置，互不干扰。你放进去多少东西，它就占用多少空间，当然，为了效率，编译器可能会在中间塞点“棉花”（内存对齐和填充），让CPU取数据时更顺畅。这种模式的优点是显而易见的：数据完整性高，你可以随时访问任何一个成员，它们的值都是独立的。这对于需要同时持有多个相关属性的对象来说，简直是天作之合。比如一个人的姓名、年龄、身高，它们彼此独立，但又共同描述一个人。
而
union则完全是另一种逻辑了，它更像一个“多功能槽位”，或者说，一个共享的存储池。你同一时间只能把一种东西放进去。你放了个苹果，那梨就得拿出来；你放了个整数，那浮点数就没了。它的内存大小，是所有成员中最大的那个成员决定的。比如你有一个
union，里面有
int和
double，那么这个
union的大小就会是
double的大小，因为
double通常比
int大。这种设计思路，我觉得更多是出于极致的内存优化考量，尤其是在嵌入式系统或者需要处理多种数据类型但每次只关注其中一种的场景。它强制你思考“我当前真正需要的是什么”，并且牺牲了同时访问所有成员的能力。当然，这也带来了潜在的风险：如果你不小心写入了一个成员，然后去读取了另一个成员，那结果往往是未定义的行为，或者说，你读到的是一堆“乱码”，因为那块内存现在承载的是不同类型的数据的位模式。这需要开发者有非常清晰的逻辑和严格的类型追踪。在我的一些老项目里，看到前辈们用
union来处理不同消息类型的数据包，每个包头都有一个字段指示当前包的实际类型，然后用
union来解析具体内容，效率确实高，但调试起来也确实考验功力。
为什么选择结构体而非联合体？它们各自的最佳应用场景是什么？
选择结构体而非联合体，通常是出于数据完整性、可读性和维护性的优先考虑。结构体的核心价值在于它能够将一组逻辑上相关但物理上独立的数据项聚合在一起。想象一下，你正在设计一个表示“学生”的数据类型，你肯定会需要同时存储学生的姓名（字符串）、学号（整数）、年龄（整数）和平均成绩（浮点数）。这些信息是并存的，你不会说“学生要么有姓名，要么有学号”，它们是共同构成一个学生的完整画像。在这种情况下，
struct Student { std::string name; int id; int age; double gpa; }; 就是最自然、最安全的选择了。它保证了每个成员都有自己的存储空间，你可以随时访问任何一个属性而不会影响到其他属性。它的最佳应用场景几乎涵盖了所有需要聚合多种独立数据来描述一个实体的场合，例如对象的状态、数据库记录、配置参数等。它提供了清晰的语义和安全的并发访问（针对不同成员）。
立即学习“C++免费学习笔记（深入）”；
而联合体，它的最佳应用场景则聚焦于内存效率和类型多态性（运行时根据需要存储不同类型数据）的特定场景。一个典型的例子是，当你需要定义一个“值”类型，这个值可能是一个整数，也可能是一个浮点数，或者是一个字符串，但你明确知道在任何给定时间点，它只会是其中一种。例如，一个解析器可能在处理一个抽象语法树节点时，这个节点的值可能是数字常量，也可能是字符串常量。如果使用
struct，你需要为所有可能的类型都分配空间，即使大部分时候它们是空的，这会造成内存浪费。但如果用
union，你就可以这样设计：
union Value { int i; double d; char* s; };。当然，为了安全使用，你还需要一个额外的“标签”字段来指示当前union里存储的是哪种类型的数据，例如：
struct TaggedValue { enum Type { INT, DOUBLE, STRING } type; union Value data; };。这种模式在实现变体类型（如C++17的std::variant，它在底层可能就利用了类似
union的机制，但提供了类型安全保障）或者在通信协议中处理不同消息体时非常有用，因为它能在内存受限的环境下提供极高的存储效率。但切记，使用
union时，管理其当前活跃成员的责任完全落在了开发者身上，一旦出错，程序行为将变得不可预测。
C++标准如何规定结构体和联合体的内存对齐与填充？
C++标准对结构体和联合体的内存对齐与填充有着明确但又留有一定实现自由度的规定。其核心目的是为了确保程序在不同硬件架构上能够高效运行，因为许多处理器在访问非对齐数据时会效率低下，甚至会引发硬件异常。
对于结构体而言，标准规定：
- 成员顺序： 成员在内存中的顺序与它们在结构体中声明的顺序一致。这是最基本的保证。
- 对齐要求： 每个成员都有一个自身的对齐要求（alignment requirement），通常是其大小的某个幂次方（如1字节、2字节、4字节、8字节）。结构体本身的对齐要求是其所有成员中最大对齐要求的那个。
-
填充（Padding）： 编译器可能会在成员之间插入额外的字节（填充），以确保后续成员能够满足其自身的对齐要求。例如，在一个32位系统上，如果一个
char
后面跟着一个int
，char
可能只占1字节，但int
需要4字节对齐。那么编译器会在char
后面填充3个字节，使得int
从一个4字节对齐的地址开始。 - 末尾填充： 结构体的总大小通常是其最大对齐要求的整数倍。如果结构体所有成员加起来的总大小不是其对齐要求的倍数，编译器会在结构体末尾添加填充，以确保数组中的下一个结构体实例也能正确对齐。
举个例子：
struct Example {
char c1; // 1 byte
int i; // 4 bytes
char c2; // 1 byte
short s; // 2 bytes
};
// 假设默认对齐是4字节
// c1 (1 byte) [c1][pad][pad][pad]
// i (4 bytes) [i ][i ][i ][i ]
// c2 (1 byte) [c2][pad][pad]
// s (2 bytes) [s ][s ]
// 总大小：1 (c1) + 3 (pad) + 4 (i) + 1 (c2) + 1 (pad) + 2 (s) + 2 (pad) = 14 bytes
// 实际上，最大对齐是int的4字节，所以总大小会是4的倍数，16字节。
// [c1][pad][pad][pad][i ][i ][i ][i ][c2][pad][s ][s ][pad][pad][pad][pad]
// sizeof(Example) 可能会是16这种填充虽然增加了内存占用，但显著提升了CPU访问效率。
对于联合体而言，规则则简化得多：
- 内存共享： 所有成员都从联合体的同一个内存地址开始存储。
- 大小： 联合体的总大小等于其所有成员中最大成员的大小。
- 对齐： 联合体的对齐要求是其所有成员中最大对齐要求的那个。联合体本身会根据这个最大对齐要求进行对齐。
union Data {
char c; // 1 byte
short s; // 2 bytes
int i; // 4 bytes
double d; // 8 bytes
};
// 最大成员是double，占用8字节，对齐要求通常也是8字节。
// 所以 sizeof(Data) 会是8。
// 无论你存c, s, i, 还是d，都占用这8字节。这意味着联合体内部不会有成员之间的填充，因为它本质上只是一个足够大的内存块，可以容纳任何一个成员。末尾填充可能存在，以确保整个联合体实例能满足其最大成员的对齐要求。编译器通常提供
#pragma pack或
__attribute__((packed))等扩展来控制或禁用这种对齐和填充，但这会牺牲可移植性和性能，需谨慎使用。
在面向对象设计中，联合体是否还有一席之地？如何安全地使用它们？
在现代C++的面向对象设计（OOD）中，裸的（plain）联合体（
union）的使用场景确实变得越来越少，甚至可以说有些边缘化。原因很简单：OOD强调封装、继承和多态，以及类型安全。裸联合体天
