3. pragma pack指令：掌控内存对齐的终极武器
说实话，刚入行那会儿，我对 #pragma pack 这玩意儿是有点抵触的。总觉得它破坏了编译器默认的对齐规则，像个「野路子」。直到有一次，我在做一个嵌入式项目，需要把结构体直接映射到硬件寄存器上——嗯，那一次差点把我整崩溃。
默认对齐下，结构体里塞了几个 uint8_t 和 uint32_t，结果实际占用的内存比我想象的大了一圈。硬件那边死活读不到正确的数据。后来老同事看了一眼，轻飘飘说了句：「加个 #pragma pack(1) 试试。」问题秒解。从那天起，我就老老实实把这套东西学透了。
3.1 #pragma pack(n)：手动指定对齐系数
#pragma pack(n) 的作用，说白了就是告诉编译器：「哥们，别按默认的来了，按我说的 n 值对齐。」这里的 n 一般是 1、2、4、8、16 这些 2 的幂次。
它的对齐规则是这样的：每个成员的偏移量，取「自身大小」和「n」中较小的那个。举个例子你就明白了。
#pragma pack(2) // 指定按 2 字节对齐
struct PackedStruct {
char a; // 1字节，偏移0
int b; // 4字节，min(4,2)=2，偏移2
short c; // 2字节，min(2,2)=2，偏移6
};
#pragma pack() // 恢复默认对齐
你看，int b 本来默认要对齐到 4 字节边界，但现在 n=2，所以它只对齐到 2 字节边界。整个结构体大小也从默认的 12 字节降到了 8 字节。
核心要点： #pragma pack(n) 不是「强制所有成员按 n 对齐」，而是「取成员自身大小和 n 的最小值」。这是个常见的误解，我见过不少新手在这上面栽跟头。
3.2 pack(1)：紧凑结构体的终极方案
当 n=1 时，所有成员都按 1 字节对齐。这意味着什么？结构体里没有任何填充字节，成员一个紧挨一个。这就是所谓的「紧凑结构体」。
#pragma pack(1)
struct CompactStruct {
char a; // 偏移0
int b; // 偏移1
short c; // 偏移5
double d; // 偏移7
};
#pragma pack()
// 大小 = 1 + 4 + 2 + 8 = 15 字节
// 默认对齐下，这个结构体至少 24 字节
15 字节对 24 字节，省了将近 40% 的空间。我在做网络协议解析的时候特别喜欢用这个。想想看，一个网络包的结构体，如果按默认对齐，解析出来的字段位置全乱了，那还玩个啥？
我的经验： 凡是需要和外部设备、文件、网络交互的结构体，我习惯一律加上 #pragma pack(1)。省心，不出错。但如果是纯内存计算的结构体，我会慎重——紧凑结构体访问速度会慢一些，因为 CPU 读未对齐的数据需要额外操作。
3.3 pack(push/pop)：栈式管理，优雅又安全
你想想看，如果整个文件都设成 pack(1)，那后面的结构体全受影响。万一某个结构体需要高性能访问，希望用默认对齐呢？这就尴尬了。
好在编译器提供了 push/pop 机制。它就像一个栈：push 把当前对齐设置压栈，然后设置新的值；pop 恢复之前的值。完美解决了作用域问题。
// 默认对齐
struct NormalStruct {
int a;
double b;
};
#pragma pack(push, 1) // 保存当前对齐，设为1
struct PackedStruct {
char a;
int b;
double c;
};
#pragma pack(pop) // 恢复之前保存的对齐
// 这里的 NormalStruct 不受影响，还是默认对齐
我个人习惯的做法是：永远用 push/pop 配对使用。哪怕只有一个结构体需要特殊对齐，我也会加上 push/pop。为什么？因为代码不是写给我一个人看的。三个月后别人来维护，看到 #pragma pack(1) 孤零零挂在那，鬼知道它影响范围有多大。
我曾经踩过的坑： 有一次在头文件里用了 #pragma pack(1)，忘了 pop 回去。结果这个头文件被其他几个源文件包含，导致那些文件里所有结构体都变成了紧凑模式。一个看似无关的模块突然崩溃，查了两天才找到原因。从那以后，push/pop 就成了我的铁律。
3.4 知识体系总览
下面这张图，是我自己总结的 #pragma pack 知识脉络。每次用之前扫一眼，思路就清晰了。
3.5 实际应用中的选择建议
说了这么多，到底什么时候该用哪种？我根据自己的项目经验，整理了一个对照表：
| 场景 | 推荐做法 | 原因 |
|---|---|---|
| 网络协议解析 | #pragma pack(1) |
协议字段必须连续，不能有空洞 |
| 硬件寄存器映射 | #pragma pack(1) |
寄存器地址必须精确对应 |
| 文件格式读写 | #pragma pack(1) |
文件布局固定，不能有填充 |
| 高性能计算 | 默认对齐 | 对齐访问更快，CPU 更省力 |
| 混合场景 | push/pop |
不同结构体需要不同对齐策略 |
一个小技巧： 如果你不确定当前的对齐设置是什么，可以用 offsetof 宏来检查。比如 offsetof(struct Foo, bar) 就能告诉你 bar 成员的偏移量。我在调试对齐问题时，经常用这招来验证自己的判断。
好了，关于 #pragma pack 的内容就聊到这儿。记住一句话：对齐是编译器的默认行为，但最终决定权在你手里。用好这套工具，你的结构体就能在「省空间」和「高性能」之间找到最佳平衡点。