1. 联合体：一块内存的多面人生
1.1 先理解联合体的本质：你只能保存其中一个值
很多人刚开始接触union时，第一反应是“这不就是个结构体吗”。这个误解必须纠正。结构体的成员是“同时共存”的，每个成员都拥有独立的内存空间；联合体恰恰相反，它的所有成员共享同一块内存空间，编译器按照成员中占据内存最大的那个大小来分配空间。这句话翻译成人话就是：同一时刻，这堆字节只能以某一种成员的含义来解释。
看个最直观的例子：
#include <stdio.h> union Exmaple { int i; float f; char bytes[4]; }; int main(void) { union Exmaple u; u.i = 0x3F800000; // 这就是 1.0 的 IEEE 754 表示 printf("作为 int 看: %d\n", u.i); printf("作为 float 看: %f\n", u.f); printf("作为字节看: %02X %02X %02X %02X\n", (unsigned char)u.bytes[0], (unsigned char)u.bytes[1], (unsigned char)u.bytes[2], (unsigned char)u.bytes[3]); return 0; }你写入u.i，再以u.f读出，得到的是同一个二进制位模式按浮点数解释出来的结果。整个过程没有做任何类型转换，只是“换了一种视角去看同一段内存”。这正是联合体最核心的价值：同一块数据，不同解释方式。
1.2 联合体的大小别想当然：对齐才是关键
有个高频面试题叫“这个 union 占几个字节”，十个人有八个算错。关键规则是：联合体的大小要大到能容纳下最大成员，并且要满足所有成员的对齐要求。这意味着union { char c; double d; }的大小绝不是 8 这么简单，它必须是double对齐数的整数倍。
实测一下（64 位系统，GCC 默认设置）：
#include <stdio.h> union U1 { char c; int i; }; union U2 { char c; double d; }; union U3 { char str[13]; int arr[2]; }; int main(void) { printf("U1: %zu\n", sizeof(union U1)); // 8，不是 4 printf("U2: %zu\n", sizeof(union U2)); // 8，不是 9 printf("U3: %zu\n", sizeof(union U3)); // 16，不是 13 return 0; }U1最大成员是int占 4 字节，但union的大小被对齐到 4 的整数倍，所以是 4？不对，这里要小心，不同编译环境下结果是 4 或者 8。为什么有人会算出 8？因为有些教学代码里加了其他成员或者编译器默认对齐策略不同。U2里有double，对齐要求是 8，所以整个union的大小必须也是 8 的倍数；可成员一个char一个double，最大才 8，所以大小是 8。U3里str[13]对齐要求是 1，int arr[2]对齐要求是 4，编译器把大小圆整到 4 的倍数，得到 16，剩下的 3 个字节是填充字节。
注意：
union内部有填充字节很正常，你永远不应该假设某个成员正好从偏移 0 开始紧挨着放。
1.3 联合体的三个典型应用场景
第一个场景是节省内存。在嵌入式或者网络协议栈里，一条消息可能有不同类型的载荷：控制帧短、数据帧长、状态帧更短。给每种帧单独定义一个结构体再塞到一个大结构体里，内存立刻浪费一半。用union包一层，整体按最大成员分配，内存只花一份。
第二个场景是类型双关。Linux 内核里有个常用手法：把uint32_t拆成 4 个uint8_t用。用联合体做字节拆分，比手动移位直观得多。不过要提醒一句：C 标准对“写入一个成员然后读另一个成员”的行为说得并不像 C++ 那么严格，在 C 语言的类型双关（type punning）实践里，联合体是被广泛接受的做法，但仍建议在可移植要求极高的代码里留意编译器的特殊处理。
第三个场景是解析二进制协议。报文到达后，你并不想频繁移位抠位，直接把缓冲区memcpy到联合体，然后按字段读即可。只要注意字节序问题，这个方案能让代码大幅简化。
1.4 匿名联合体：C11 带来的福利
C11 允许匿名联合体，也就是说联合体不需要名字，直接用成员名访问：
#include <stdio.h> struct Vec { union { struct { float x, y, z; }; struct { float r, g, b; }; float data[3]; }; }; int main(void) { struct Vec v = { { .x = 1.0f, .y = 0.0f, .z = 0.5f } }; printf("x=%f r=%f data[0]=%f\n", v.x, v.r, v.data[0]); return 0; }这样写的好处是既能用v.x这种语义化名字，也能用v.data[0]遍历内存，还能在需要时用v.r把它当颜色值处理。图形学代码、数学库、顶点数据解析里这种写法非常多，因为它几乎不产生额外成本。
2. 枚举：给数字起一个你能看懂的名字
2.1 枚举底层就是整数，别把它想得太玄
enum在 C 语言里的本质是“命名整数常量集合”。你写：
enum Color { RED, GREEN, BLUE };编译器自动让RED = 0、GREEN = 1、BLUE = 2。它不让直接用RED当int用吗？让，在 C 语言里enum和int之间的转换几乎不需要注意什么，这也导致了很多人觉得“枚举不就是#define换了个皮”。
但相信我，换皮只是看着像，实际带来的收益不是#define能比的：调试器里能看到名字，不是干巴巴的2；做 switch 时编译器能给未处理分支警告；函数参数写明enum类型比写int更有意图。
2.2 枚举值的自动编号规则和手动赋值陷阱
默认从 0 开始，逐个加 1。如果你手动给中间项赋值，后面的项会接着它的值继续加：
enum Status { OK, // 0 WARN, // 1 FAIL = 10, // 10 FATAL // 11 };陷阱在哪？第一个：你可以在同一个枚举里反复赋同样的值，编译器不报错：
enum Dup { A = 5, B, C = 5 };A和C相等，这通常意味着逻辑错误，但编译器只是给个警告或者干脆不提示。第二个陷阱是枚举变量本质是int，所以可以赋任意整数值，这在 C 里合法但违背了枚举的初衷：
enum Color c = 100; // 能编过，但这是无效颜色强类型语言看到这种代码会直接报错，C 语言不会。所以自己得留个心眼，特别是写状态机时，进入 switch 务必加default分支拦截非法值。
2.3 枚举的三个高频用法
用法一是状态机。状态机的核心就是“当前处于哪个状态”，最自然的实现就是枚举状态：
enum State { ST_IDLE, ST_RUNNING, ST_PAUSED, ST_STOPPED };哪怕只存一个状态圈转来转去，也比用裸int加一堆#define清晰得多。
用法二是错误码。系统编程里返回错误码是常态，用枚举把错误码组织起来，同一接口的调用方一眼就能看出可能返回哪些错误：
enum ErrorCode { ERR_NONE = 0, ERR_NULL_PTR, ERR_INVALID_ARG, ERR_TIMEOUT, ERR_IO_FAIL };用法三是枚举当数组下标。利用枚举值从 0 开始连续的特性，直接做索引：
enum Fruit { APPLE, BANANA, ORANGE, FRUIT_COUNT // 这个技巧很好用 }; int prices[FRUIT_COUNT]; prices[APPLE] = 5;FRUIT_COUNT这个哨兵值特别实用，以后加水果，数组大小自动跟着变。
3. 联合体 + 枚举：一个模式打天下
3.1 带标记的联合体（tagged union）
联合体的最大弱点就是我前面提到的：如果你不知道当前写入的是哪个成员，读出来的就是一滩意义不明的字节。解决办法也很经典：加一个枚举“标签”，记录当前存的是什么类型。这就是标签联合体（tagged union），C 语言里最常见的组合模式之一：
enum DataType { TYPE_INT, TYPE_FLOAT, TYPE_STR }; struct Data { enum DataType type; union { int i; float f; const char *str; }; };使用的时候永远先查type，再访问对应成员：
void print_data(const struct Data *d) { switch (d->type) { case TYPE_INT: printf("int: %d\n", d->i); break; case TYPE_FLOAT: printf("float: %f\n", d->f); break; case TYPE_STR: printf("str: %s\n", d->str); break; default: printf("unknown type\n"); } }这种模式在编译器前端（抽象语法树节点）、解释器（变量值类型）、GUI 工具包（事件类型）、网络协议解析里都极其常见。它解决的问题很朴素：联合体省了内存但丢了类型信息，枚举和结构体组合补回了类型信息，取两者之长。
3.2 命令分发表：更进阶的组合玩法
标签联合体一般和switch搭配，但命令数量一多，switch会变得又臭又长。这时候可以引入函数指针表：
struct Command { enum CmdType type; union { struct { int a, b; } move; struct { int x; } stop; struct { const char *msg; } notify; }; }; typedef void (*cmd_handler_t)(const struct Command *cmd); static void handle_move(const struct Command *cmd) { printf("move to (%d, %d)\n", cmd->move.a, cmd->move.b); } static void handle_stop(const struct Command *cmd) { printf("stop at %d\n", cmd->stop.x); } static void handle_notify(const struct Command *cmd) { printf("notify: %s\n", cmd->notify.msg); }分发时不再写超长switch，直接查表：
static const cmd_handler_t handlers[] = { [CMD_MOVE] = handle_move, [CMD_STOP] = handle_stop, [CMD_NOTIFY] = handle_notify };记住一个附加项：数组下标用枚举值，天然安全且高效，新命令只需加枚举值和对应处理函数。
3.3 这个模式的红线：初始化与类型一致性
标签联合体最大的风险在于“标签和数据不一致”。比如type写的是TYPE_INT，但你塞进去的其实是float的数据位。编译器不会也不能发现。规避手段有三：
第一，提供“构造函数”风格的接口，禁止外部直接改联合体成员。比如struct Data data = make_int(42);，这类函数统一处理赋值和设置标签，外部代码就不容易搞乱。
第二，读数据时永远走访问函数，不要直接读联合体成员。访问函数内部先断言type正确，再返回值。
第三，在嵌入式等对内存布局敏感的场景，给标签字段加注释说明，跨平台移植时优先检查字节序和对齐方式，避免数据解析错位。
4. 实战中遇到的那些高危坑位与排查思路
4.1 常见问题速查表
下面这张表是我在代码里和帮别人 review 时最常遇到的联合体/枚举问题，基本覆盖了 90% 的“看起来没错但跑起来就是不对”的情况。
| 问题现场 | 根因 | 排查思路 | 解决方案 |
|---|---|---|---|
| 联合体读出来的 float 是个天文数字 | 写入成员和读取成员不是同一个，且没有 tag | 检查 tag 是否在赋值时同步更新 | tag 联合体模式或者写访问函数 |
联合体sizeof和预期不符 | 没算对齐填充 | 用sizeof和offsetof打印验证 | 别硬编码大小，程序里动态计算 |
枚举值传给printf("%s")输出了乱码 | 枚举本质是整数，不是字符串 | 打印%d，或者写转换函数 | 用 switch 映射或查找表转字符串 |
| 枚举 switch 漏掉某个分支且编译器无提醒 | C 语言编译器默认不开启-Wswitch强化检查 | 编译加-Wall -Wextra -Wswitch-enum | 所有枚举分支都写上，default兜底 |
| 网络字节序和主机字节序不一致导致拆包错误 | 联合体拆分变量时忽略了大端/小端 | 用十六进制打印字节再对比 | 统一用ntohs/ntohl或手动字节序转换 |
| 把枚举变量赋了非法值 | C 的枚举没有强类型检查 | code review 时留意赋值来源 | 入口处加校验函数，非法值走 default |
枚举值大于int范围 | 编译器按int处理枚举值 | 打印sizeof(enum)确认 | 换uint32_t常量或加编译器选项 |
4.2 大小端问题：联合体拆字节的“最佳翻车现场”
联合体做字节拆分太方便了，方便到容易忘记字节序。比如把一个uint16_t塞进出联合体，然后读两个uint8_t，在小端机器上低字节在前，大端机器上高字节在前。协议规定“必须先传高字节”，你直接塞联合体就错了，必须先htons。
一个稳妥做法是用移位，不直接依赖联合体拆分网络字节序数据。或者拆完后每次读字节时按协议显式组合：
uint16_t be16(const unsigned char *p) { return ((uint16_t)p[0] << 8) | p[1]; }这种代码无论什么平台跑出来都一样，符合直觉，也不会被字节序坑。联合体适合“同一个数据的多种视角”，而网络协议里的“结构“天然是字节序相关的，直接搬联合体偷懒，后面出的都是疑难杂症。
4.3 编译层面的避坑建议
编译时把这些选项打开，能在编译阶段拦截大量错误：
gcc -std=c11 -Wall -Wextra -Wpedantic -Wswitch-enum -Wshadow-Wswitch-enum对“枚举 switch 没覆盖全”特别有用。C 语言虽然不像 C++ 那样的枚举类那么严格，编译器的警告能补一部分类型安全的短板。
提示：如果你发现
sizeof(enum)在不同平台不一致，GCC 有-fshort-enums可以压缩枚举宽度，但这个选项会让 ABI 变得不可预测，跨模块传枚举时强烈不建议开启。真需要小宽度，用uint8_t显式控制。
5. 写在最后的个人折腾心得
联合体和枚举都不是 C 语言里“高大上”的东西，但用得好不好，直接影响代码可读性和内存效率。我接触过不少把联合体用得极其混乱的代码，也见过把用户工业协议解析写得像天书的项目。回头总结，最核心的一条经验是：联合体省的是内存空间，但必须用额外的信息换回来，这个额外信息通常就是枚举。用 tag 字段明确告诉你“现在这个联合体里住着谁”。
如果你刚接触这两个概念，建议从标签联合体入手练手，自己写一个支持收不同报文的小程序，体会一下“一块内存 + 一个标签”到底是怎么支撑起复杂逻辑的。刚开始可能觉得多写几行代码麻烦，稍加熟练之后就会发现，这种写法在保持结构清晰的同时，还让你省下了大量重复代码，尤其在数据种类多、内存又宝贵的场景里，真是一招鲜。
最后一个小技巧：枚举转换字符串这种操作，别写一堆 if-else 或 switch，用查表法，全局数组加哨兵值，一行初始化搞定。
比如：
static const char * const color_names[] = { [RED] = "red", [GREEN] = "green", [BLUE] = "blue", [COLOR_COUNT] = NULL };插入新颜色时只要在枚举里加一项并把字符串加到对应位置，查表函数都不需要改。实用性和可维护性直接拉满。
联合体和枚举这两个自定义类型，配合结构体用，几乎能覆盖你日常开发中的绝大多数“多类型数据管理”需求。多写、多折腾，你会慢慢找到自己的节奏。
