在C语言里，结构体变量占用的内存往往比所有成员大小加在一起更大，原因是编译器会在成员之间插入若干填充字节。内存对齐并不是标准强制规定的精确布局，而是由平台ABI和编译器共同决定的一种优化策略。当结构体仅用于程序内部逻辑时，这种对齐有助于提高CPU存取效率；但当结构体需要通过网络发送、写入二进制文件或与硬件寄存器直接映射时，未加控制的填充字节就会导致数据错位。此时，最常用的控制手段就是#pragma pack指令。理解它的作用方式以及使用边界，是掌握C语言底层内存布局能力的重要一环。

内存对齐的基本规则与计算

编译器在对结构体成员进行排布时，每个成员都有各自的对齐要求。例如在大多数平台上，char类型的对齐值为1，int类型为4，double类型为8。成员在结构体中的偏移量必须是其对齐值的整数倍。如果前一个成员结束位置不满足这一条件，编译器就会插入空白填充字节。

以一个包含char、int、char三个成员的结构体为例，假设int对齐值为4。第一个char占用偏移0处的一个字节，第二个int需要满足偏移量为4的整数倍，因此从偏移1到3要填充3个字节，int放在偏移4到7，最后的char放在偏移8。此时结构体总大小为9字节，但结构体自身的对齐值取决于成员中最大的对齐值，也就是int的4字节，因此总大小必须补齐到4的整数倍，最终变成12字节。我们可以通过sizeof观察到这个结果。

#include <stdio.h>
struct Example {
    char a;
    int b;
    char c;
};
int main(void) {
    printf("%zu\n", sizeof(struct Example));
    return 0;
}

不同成员的排列顺序会显著影响最终大小。如果把两个char放在一起，再把int放到后面，结构体大小会从12字节降为8字节。这说明默认对齐方式虽然能减少非对齐访问，但也可能因为成员声明顺序不当而浪费内存。出于这个原因，不少工程规范会建议将占用空间较大、对齐值较高的成员声明在结构体靠前的位置。

#pragma pack的作用与语法

#pragma pack用来调整编译器的对齐系数，从而改变结构体成员的有效对齐值。有效对齐值等于成员自身对齐值与pack指定值中的较小者。比如成员是int，默认对齐为4，当执行#pragma pack(1)后，有效对齐变为min(4,1)=1，于是int可以紧跟在char之后，不需要再插入3个填充字节。

基本语法包括#pragma pack(n)设置新的对齐值，#pragma pack()恢复为默认对齐。更推荐的做法是使用#pragma pack(push, n)来保存当前对齐状态并设置新值，结构体定义结束后用#pragma pack(pop)恢复。push与pop可以由编译器维护一个状态栈，适合在头文件中安全地包裹需要紧凑布局的结构体。

#include <stdio.h>
#pragma pack(push, 1)
struct TightLayout {
    char a;
    int b;
    char c;
};
#pragma pack(pop)
int main(void) {
    printf("%zu\n", sizeof(struct TightLayout));
    return 0;
}

这段代码中的结构体在pack(1)控制下，成员之间没有任何填充。char占用偏移0，int直接放在偏移1到4，第二个char放在偏移5，总大小为6字节。由于有效对齐值为1，结构体总大小也只需是1的整数倍，所以不会再有尾部填充。若将参数改为2，int的对齐值变为min(4,2)=2，因此int会从偏移2开始，最终结构体大小通常是8字节。

使用#pragma pack的注意事项

第一点是push和pop必须成对出现。很多项目会把紧凑结构体放在公共头文件中，如果只写了#pragma pack(push, 1)而忘记写#pragma pack(pop)，后续所有包含该头文件的代码都会受到影响。更隐蔽的是，这种影响不会立即报错，而是通过sizeof发生细微变化，导致二进制兼容问题或内存异常。

第二点是放置位置。pack指令只对出现在它之后的结构体定义有效，对已经定义过的结构体没有追溯效果。例如先定义了一个结构体，再写#pragma pack(1)，再声明一个同类型变量，原有结构体布局不会改变。因此必须把pack指令放在目标结构体定义之前。在组织代码时，最好将紧凑布局的结构体独立出来，并用push/pop清楚划定作用范围。

第三点是跨编译器差异。GCC、Clang和MSVC都支持#pragma pack，但个别语法细节存在差异。例如MSVC支持#pragma pack(show)输出当前对齐值，而GCC和Clang不一定支持。对于需要同时被多种编译器编译的代码，建议不要依赖厂商扩展参数，只用push、pop和基础数值形式，并用宏隔离可能出现的扩展用法。

第四点是性能影响。pack(1)会让数据按任意字节地址存取，在x86架构下通常能正常工作，但会引入额外的读取开销，因为CPU需要处理未对齐的内存访问。在ARM等RISC架构上，未对齐访问可能直接触发硬件异常。因此紧凑布局只应该用于网络报文、文件格式、固件协议等必须精确控制字节的场景，普通计算型结构体应保留默认对齐。

用offsetof和静态断言验证结构体布局

仅凭脑内计算很容易搞错对齐后的偏移量和总大小，尤其是在嵌套结构体、数组成员以及位域同时存在时。C语言标准库提供了offsetof宏，用来获取成员相对于结构体起始位置的字节偏移量。把它与sizeof组合使用，可以在编译阶段或测试阶段验证真实布局是否符合预期。

下面代码使用offsetof检查pack(1)结构体中各个成员的偏移量，并通过_Static_assert在编译期强制校验大小。如果实际布局与预期不符，编译器会直接报错，避免问题流入运行期。

#include <stdio.h>
#include <stddef.h>
#pragma pack(push, 1)
struct Packet {
    char type;
    int length;
    char data[3];
};
#pragma pack(pop)
_Static_assert(sizeof(struct Packet) == 8, "unexpected packet size");
_Static_assert(offsetof(struct Packet, length) == 1, "unexpected length offset");
_Static_assert(offsetof(struct Packet, data) == 5, "unexpected data offset");
int main(void) {
    printf("size=%zu, length_offset=%zu\n",
           sizeof(struct Packet),
           offsetof(struct Packet, length));
    return 0;
}

该结构体在pack(1)下的大小为8字节：type占1字节，length占4字节，data占3字节。偏移量分别是0、1和5。通过静态断言可以确保换用不同编译器或不同版本时，布局仍然保持一致。如果目标平台不支持_Static_assert，也可以退回到运行期断言，但编译期检查明显更可靠。

另外要留意，#pragma pack只能调整对齐填充，不能改变字节序。跨机器传输多字节整数时，还需要使用htonl、htons等函数显式转换网络字节序。单靠紧凑结构体并不能解决所有二进制一致性问题。