6、结构体对齐：内存对齐的规则与#pragma pack的使用
结构体对齐这个话题，说实话，我见过太多工程师在这上面栽跟头了。记得我刚入行那会儿，写了一个通信协议的结构体，直接往里面塞数据，结果在不同平台间传输时数据全乱了。排查了整整两天，最后发现是结构体对齐在搞鬼。从那以后，我对这块就特别上心。
什么是结构体对齐？
说白了，就是编译器为了让CPU访问数据更高效，会在结构体成员之间插入一些填充字节。CPU读取内存时，通常是以4字节或8字节为单位读取的。如果数据没有对齐到合适的地址，CPU就需要多读一次，甚至引发总线错误。
举个例子，你定义了一个结构体：
struct Test {
char a; // 1字节
int b; // 4字节
short c; // 2字节
};你猜猜这个结构体占多少字节？很多人会脱口而出：1+4+2=7字节。但实际上，在32位系统上，它占12字节。为什么会这样？
因为编译器会在a后面填充3个字节，让b对齐到4字节边界。然后在c后面再填充2个字节，让整个结构体的大小是最大成员（int，4字节）的整数倍。
内存对齐的三大规则
我个人习惯把对齐规则总结成三条，好记又实用：
- 每个成员的起始地址必须是其自身大小的整数倍。比如int是4字节，它的起始地址必须是4的倍数。
- 结构体的总大小必须是最大成员大小的整数倍。如果最大成员是double（8字节），那结构体总大小必须是8的倍数。
- 结构体本身的起始地址也必须是最大成员大小的整数倍。这个规则在结构体嵌套时特别重要。
核心要点：对齐的本质是用空间换时间。填充字节虽然浪费了内存，但换来了更快的访问速度。
我在项目中遇到的对齐陷阱
有一次，我写了一个网络协议解析模块，结构体定义如下：
struct Packet {
char type; // 1字节
uint32_t len; // 4字节
char data[0]; // 柔性数组
};然后我直接用memcpy把收到的数据拷贝到这个结构体上。结果呢？len字段的值总是错的。原因就是type后面有3个填充字节，而协议数据里根本没有这些填充字节。
嗯，这里要注意：当结构体用于网络通信或文件存储时，对齐方式必须和协议定义完全一致。否则就会出现数据错位的问题。
#pragma pack 的使用
为了解决对齐带来的问题，C语言提供了#pragma pack指令。它可以改变编译器的对齐方式，说白了就是告诉编译器：「别给我加那些填充字节了，按我说的来。」
基本用法：
#pragma pack(1) // 按1字节对齐，即取消对齐
struct PackedStruct {
char a;
int b;
short c;
};
#pragma pack() // 恢复默认对齐
// 此时 sizeof(PackedStruct) == 7你想想看，如果#pragma pack(1)，那所有成员都紧挨着存放，没有填充字节。这在处理二进制协议时特别有用。
不同对齐值的对比
| 对齐方式 | 结构体大小 | 访问效率 | 适用场景 |
|---|---|---|---|
| 默认对齐（4字节） | 12字节 | 高 | 普通内存操作 |
| #pragma pack(1) | 7字节 | 低 | 网络协议、文件格式 |
| #pragma pack(2) | 8字节 | 中 | 某些嵌入式系统 |
警告：使用#pragma pack(1)后，访问未对齐的成员可能会导致性能下降，在某些ARM平台上甚至会触发硬件异常。我曾经在STM32上遇到过这种情况，程序跑着跑着就进HardFault了，排查了半天才发现是pack后的结构体成员访问出了问题。
结构体对齐的SVG知识图谱
避坑指南
我曾经在写一个跨平台的通信库时，遇到过这样一个问题：在Windows上编译的结构体大小是12字节，在Linux上却是16字节。原因就是两个平台的默认对齐方式不同。Windows是4字节对齐，而Linux是8字节对齐。
所以，我的建议是：
- 如果结构体只在本模块内部使用，用默认对齐就好，性能最优。
- 如果结构体要跨平台传输或持久化，一定要用
#pragma pack(1)，并且显式地控制每个字段的字节序。 - 在嵌入式系统中，特别是ARM Cortex-M系列，尽量避免使用pack(1)后的结构体成员进行频繁访问，性能损失可能超出你的预期。
小技巧：如果你不确定结构体的对齐方式，可以用offsetof宏来检查每个成员的偏移量。比如offsetof(struct Test, b)就能告诉你b字段的偏移位置。我在调试对齐问题时，经常用这个宏来验证自己的判断。
最后说一句，结构体对齐不是玄学，它是有明确规则的。理解了这些规则，你就能在空间和效率之间做出合理的选择。别像我当年那样，等到出了问题才回头研究对齐，那代价就大了。