一、字节对齐的“潜规则”与#pragma pack的由来
做嵌入式开发的朋友，十有八九都被结构体字节对齐坑过。我当年刚入行时，写了一个通信协议的结构体，明明每个字段都定义对了，可数据发出去就是解析不对。折腾了半天，才发现是编译器偷偷在结构体里塞了填充字节。说白了，这就是字节对齐在作怪。
CPU访问内存时，并不是一个字节一个字节地读。它喜欢按“字”来读——32位处理器一次读4字节，64位一次读8字节。为了让读写更高效，编译器会把结构体成员的起始地址对齐到它自身大小的整数倍上。比如一个int占4字节，它的地址就得是4的倍数。这就会在成员之间插入填充字节（padding）。
但有些场景下，我们不需要这种“好心”的对齐。比如你要把一个结构体直接映射到网络协议包上，或者映射到硬件寄存器地址上——这时候填充字节就是灾难。怎么办？#pragma pack就是用来关掉或控制这个对齐行为的。
核心理解：#pragma pack 的本质是告诉编译器：“别自作主张加填充，按我说的对齐方式来。”
二、#pragma pack 的语法与用法
2.1 基本语法
#pragma pack(n) // 设置对齐值为 n 字节（n 通常为 1, 2, 4, 8, 16）
// ... 结构体定义 ...
#pragma pack() // 恢复默认对齐（取消 pack 效果）n 表示“最大对齐值”。结构体每个成员的对齐方式，取“成员自身大小”和“n”中较小的那个。举个例子：如果 n=2，那么即使你有一个 int（4字节），它也只能按2字节对齐，不会按4字节对齐。
2.2 三种常用模式
| 写法 | 含义 | 典型场景 |
|---|---|---|
#pragma pack(1) |
按1字节对齐（完全紧凑） | 网络协议解析、二进制文件读写 |
#pragma pack(2) |
按2字节对齐 | 某些16位MCU的寄存器映射 |
#pragma pack() |
恢复编译器默认对齐 | 包作用域结束后必须恢复 |
我的习惯：每次用 #pragma pack 时，一定成对出现。在头文件里定义完结构体后，立即用 #pragma pack() 恢复。否则整个文件后续的结构体都会受影响，这种bug极难排查。
三、实战案例：网络协议解析
我记得有一次做TCP/IP协议栈的移植，需要解析以太网帧头。标准以太网帧头是14字节：6字节目的MAC、6字节源MAC、2字节类型。如果不用pack(1)，编译器会在某个字段后面塞填充，帧头就变成16字节了——整个协议栈都会崩掉。
#pragma pack(1)
typedef struct {
uint8_t dst_mac[6]; // 6字节
uint8_t src_mac[6]; // 6字节
uint16_t ether_type; // 2字节
} ethernet_header_t; // 总大小：14字节（无填充）
#pragma pack()你看，加了pack(1)之后，sizeof(ethernet_header_t) 就是14，跟协议完全一致。这时候你可以直接把结构体指针强转成接收缓冲区地址，直接读取字段，不需要手动偏移计算。
注意：pack(1) 虽然紧凑，但会导致非对齐访问。在ARM Cortex-M0这类不支持非对齐访问的MCU上，直接访问pack(1)结构体中的uint32_t成员，可能会触发硬件异常。我的建议是：协议解析时用memcpy逐字段拷贝，不要直接解引用。
四、实战案例：硬件寄存器映射
做底层驱动时，经常要把结构体映射到某个外设的寄存器地址上。比如一个UART外设，寄存器地址是连续的：数据寄存器(1字节)、状态寄存器(1字节)、控制寄存器(1字节)。如果不用pack，编译器可能会在中间填充，导致映射错位。
#pragma pack(1)
typedef struct {
volatile uint8_t dr; // 数据寄存器 (偏移0x00)
volatile uint8_t sr; // 状态寄存器 (偏移0x01)
volatile uint8_t cr; // 控制寄存器 (偏移0x02)
} uart_reg_t;
#pragma pack()
#define UART_BASE ((uart_reg_t*)0x40001000)这样，UART_BASE->dr 就直接访问到了0x40001000，UART_BASE->sr 访问0x40001001。完全符合硬件手册的地址映射。我曾经在一个项目中，因为忘了加pack(1)，结构体大小变成了3字节（实际应该是3字节），但编译器给塞成了4字节，结果控制寄存器始终写不进去——排查了整整两天。
五、知识体系与核心逻辑
下面这张图，是我自己总结的 #pragma pack 知识脉络。你可以把它当作一个快速索引，遇到相关问题先看这张图定位。
六、避坑指南与个人经验
6.1 一定要成对使用
我曾经接手过一个项目，整个工程里到处是 #pragma pack(1)，但只有少数几个地方用了 #pragma pack() 恢复。结果不同模块的结构体对齐方式完全混乱，链接在一起后，有的结构体是紧凑的，有的是默认对齐的。最后我花了一整天，把所有 pack 都清理掉，重新按模块划分，每个头文件里严格成对使用。
6.2 小心 sizeof 的陷阱
pack(1) 之后，sizeof 返回的是紧凑大小。但如果你在代码里用 sizeof 去计算缓冲区大小，然后跟其他模块交互，一定要确保对方也用了同样的 pack 设置。否则两边对结构体大小的认知不一致，轻则数据错位，重则内存越界。
6.3 非对齐访问的硬件限制
有些ARM内核（比如 Cortex-M0/M0+）不支持非对齐访问。你用 pack(1) 定义的结构体里如果包含 uint32_t 成员，而且这个成员的地址不是4的倍数，直接读取它就会触发 HardFault。我的做法是：用 memcpy 把字段拷贝到临时变量里再访问，虽然多了一次拷贝，但安全可靠。
// 安全做法：避免非对齐访问
uint32_t get_value(const void *ptr) {
uint32_t val;
memcpy(&val, ptr, sizeof(val));
return val;
}6.4 大小端问题
pack 只控制对齐，不控制字节序。如果你用 pack(1) 解析网络协议，网络字节序是大端，而你的MCU可能是小端（比如STM32）。这时候即使结构体对齐正确，读出来的 uint16_t 或 uint32_t 也是反的。别忘了用 ntohs/ntohl 做转换。
我的经验：在定义网络协议结构体时，所有多字节字段都用 uint8_t 数组表示，然后手动用移位拼接。虽然代码啰嗦一点，但彻底避免了大小端和对齐问题。比如：
// 手动解析，避免一切陷阱
uint16_t ether_type = (hdr->data[0] << 8) | hdr->data[1];七、总结
#pragma pack 是个好东西，但用不好就是坑。说白了，它给了你控制内存布局的能力，但同时也把对齐的责任交给了你。我个人建议：只在需要精确控制结构体大小时使用（协议解析、寄存器映射），并且严格成对出现。对于普通的结构体，让编译器默认对齐就好，别没事找事。
嗯，关于字节对齐和 pack 的内容就聊到这儿。记住一点：没有银弹，理解原理才能用好工具。