第一次意识到“结构体内存对齐”这个东西的存在，多半不是因为读了哪本教材，而是程序出了问题：明明往文件里写了一个5字节的结构体，读出来却占了8个字节；明明按字节流硬解析一个网络包，字段对不上号。等你盯着sizeof和offsetof的输出看半天，才发现编译器在你眼皮底下往结构体里偷偷塞了几十个填充字节。

这篇就专门把结构体的内存对齐讲透：为什么会有对齐、规则是什么、遇到结构体怎么手算大小、怎么用#pragma pack和编译器属性去主动控制对齐，以及在真实工程里常见的踩坑场景。适合刚入门C语言、对struct的sizeof结果感到迷惑的同学，也适合写了几年C但一直没有系统梳理过对齐规则的朋友。

1. 为什么结构体成员不能“一个挨一个”地存放

先回答最根本的问题：对齐不是C语言标准凭空发明的约束，而是CPU访存方式逼出来的现实。

1.1 CPU取内存的基本单位不是1个字节

很多初学者天然认为，内存就是一长串连续编号的字节，CPU想读哪个地址就按字节去拿。但现代CPU从内存读数据，并不是一次只搬运1字节，而是按“机器字”批量读取。32位平台上一次总线事务通常取4字节，64位平台上通常取8字节，读回来的数据会进入处理器内部的行缓冲，再从行缓冲里把目标字节裁出来。也就是说，CPU眼里，地址空间被划分成了一块一块的“块”，比如0x0000~0x0003是一块，0x0004~0x0007是下一块。

可以打个比方：去图书馆取书，管理员不是按本给你递，而是按一摞4本来。你只想要第5本，但他会把第5~8本一起端出来，你再挑走第1本。这个“一摞4本”就是CPU的一次行缓冲。

1.2 数据错位时的“双重读取”问题

如果一个int占据地址0x0001~0x0004，恰好横跨了两个CPU“一摞”的范围，CPU想读这个int就麻烦了：必须启动两次总线事务，先取0x0000~0x0003，再取0x0004~0x0007，然后从两份数据里各截一半，拼成一个完整int。这就是错位访问（非对齐访问）的核心代价：读写慢了一倍。

更极端的情况是，某些处理器架构不支持非对齐访问。一旦int出现在未对齐的地址上，直接触发硬件异常，程序当场崩溃。x86系列处理器内部已经做了兼容处理，错位访问只是慢；但一部分ARM核和嵌入式平台在严格模式下会直接出错。

1.3 编译器自动插入填充字节的原因

既然错位访问要么慢、要么直接异常，编译器就采取了最简单粗暴的解决方案：把每个成员安排在“合适”的起始地址上。比如一个int，尽可能让它落在4的整数倍地址处；一个short，尽可能落在2的整数倍地址处。如果前一个成员结束位置不满足后一个成员的起始对齐要求，编译器就在两者之间插入一些不用的字节。这些字节被称为“padding”，也就是填充字节。

理解到这一步，再回头看“为什么struct { char a; int b; } 不是5个字节而是8个字节”就能想通了：char总共占1字节，下一成员的int必须从4的倍数地址开始，于是编译器在a后面硬塞了3个无用字节，int从偏移4开始放。这就是结构体内存对齐最初的来源。

2. 内存对齐的四条基本规则与常见类型的对齐值

光知道“有填充”还不够，要手算结构体大小，必须把对齐规则量化成能查表、能计算的条款。

2.1 常用类型的对齐值

每种基本类型都有一个“对齐要求值”，也就是类型自身要求起始地址必须是某个整数倍的地址。同一时代下，这个值基本等于类型字节数，两个特例是double和long，在不同平台上有差异。以最常见的64位桌面/服务器平台为例，常用类型：

所以看到这里先记住一个原则：不同编译器、不同架构的对齐值可能不同，你实际写代码时不用背死“double必须是8”，用C11提供的alignof运算符查询才是准确的：

#include <stdio.h> #include <stdalign.h> int main(void) { printf("char align: %zu\n", alignof(char)); printf("int align: %zu\n", alignof(int)); printf("double align: %zu\n", alignof(double)); return 0; }

2.2 第一条规则：成员偏移量必须是对齐值的整数倍

编译器在分配结构体成员位置时，会逐个计算每个成员的偏移量。某个成员的偏移量必须是“自身对齐值与当前pack值取较小者”的整数倍，如果上一成员结束位置不满足，就填充跳过。

举一个结构体数组的例子里常见的情况：char后面跟int，char在偏移0，int的对齐值是4，偏移1、2、3都不满足要求，所以int直接放到偏移4。这一跳，就跳出了3个填充字节。

2.3 第二条规则：结构体总大小要补齐到整体对齐值的整数倍

结构体并不仅仅是“成员放完就结束”，最后还要做一次尾部填充。原因在于结构体的数组，数组要求每个元素连续排布且每个元素都能满足内部所有成员的对齐要求。

拿struct { char a; int b; }来说，如果总大小停在5，那么下一个数组元素会从偏移5开始，该元素内部的int就落在了一个不对齐的地址，循环下去整个数组都乱了。所以编译器会把结构体总大小向上补到“整体对齐值”的整数倍，这里整体对齐值就是所有成员对齐值的最大值，即4。5向上补到8，于是sizeof结果是8。

2.4 第三条规则：结构体自身的对齐值等于成员对齐值的最大值

这个概念很基础但在计算嵌套结构体时容易漏。一个结构体本身也有对齐要求，它的对齐值就是内部所有成员中对齐要求的最大值。比如struct A里有一个double成员，struct A的对齐值就是8；如果struct A里全是char，对齐值就是1。

嵌套结构体时，外层结构体把整个内层结构体当成一个“成员”，这个“成员”的对齐值正是内层结构体的整体对齐值，而不是它的sizeof大小。注意这句话，后面手算嵌套结构体时会反复用到。

2.5 第四条规则：数组成员的对齐值取元素类型的对齐值

char name[20]看着很占地方，但它的对齐值还是1，因为元素类型是char。int arr[10]的对齐值是4，不是40。分配时只关心数组的起始地址，数组内部元素自然是连续摆放的，不涉及结构体层面的额外填充。

四条规则归纳下来其实就是两句话：成员的偏移量要“对得上号”，总大小要“凑得齐整”。接下来用手算例子验证这两句话。

3. 手算几个结构体大小，验证sizeof的结果

理论说再多都不如动手算一遍。我特意挑了几个有代表性的结构体，你最好一边看一边自己在编译器里跑一下offsetof和sizeof。

3.1 最经典的陷阱：char + int

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

手算过程：

• 成员a是char，对齐值1，放在偏移0，占1字节。
• 成员b是int，对齐值4，要求偏移是4的倍数。偏移1、2、3都不行，所以填充到偏移4，占偏移4~7。
• 结构体内最大对齐值是4，总大小8正好是4的倍数，不需要尾部填充。

结果sizeof=8，offsetof(a)=0，offsetof(b)=4。如果你在协议解析里想当然认为这个结构体占5字节，后边全对不上。

3.2 两个char加一个int：顺序怎么影响空间

struct Item2 { char a; char c; int b; }; struct Item2Bad { char a; int b; char c; };

Item2成员排布：

• a偏移0，c偏移1，连续占了两个字节。
• b对齐4，从偏移4开始，占4~7。
• 最大对齐值4，总大小8。

Item2Bad排布：

• a偏移0。
• b对齐4，跳到偏移4，占4~7。
• c偏移8，占1字节。
• 总大小9，向上补齐到4的倍数，所以sizeof是12。

同样是3个成员，顺序调一调，结构体从8字节变成12字节，白丢了4字节。这里能引出一个实用结论：把对齐值大的成员往前放，把小的往后放，可以减少padding浪费。

3.3 char + double：64位下的对齐验证

struct Item3 { char a; double b; };

64位Linux下double对齐值是8：

• a偏移0。
• b对齐8，偏移1~7都不满足，直接跳到8，占8~15。
• 最大对齐值8，总大小16，不需要尾部填充。

一个char加一个double，实际只用9个字节的数据，结构体却吃掉16字节，填充字节比数据字节还多。这种结构在内存热路径上如果大量使用，浪费非常可观。

3.4 嵌套结构体的偏移量传递

嵌套结构体是很多人手算翻车的地方。看这个例子：

struct Inner { char x; int y; }; struct Outer { char z; struct Inner in; char w; };

先算Inner：

• x偏移0。
• y对齐4，从偏移4开始占4~7。
• 最大对齐值4，总大小8。

Inner的整体对齐值是4，不是它的sizeof 8。再算Outer：

• z偏移0。
• in做为一个整体成员，对齐值4，偏移必须4的倍数，所以从偏移4开始，占4~11。
• w是char，偏移12。
• 总大小13，补齐到4的倍数，sizeof结果是16。

如果此前把“内层结构体大小8”误解成“内层结构体对齐值8”，那你会把in误放到偏移8，后面全错。嵌套结构体真正传递的是它内部成员的最大对齐值。

4. 不想要默认对齐怎么办：pack与对齐属性的实战

默认对齐适合绝大多数普通内存数据处理，但有些场景必须打破默认。最典型的就是网络协议、磁盘文件格式、硬件寄存器映射——这些场景的结构体要和一段固定字节流一一对应，不能容忍编译器偷偷塞填充字节。

4.1 #pragma pack的基本用法

#pragma pack能够临时修改编译器的“最大对齐上限”。实际生效的对齐值，取“成员自身对齐值”和“当前pack值”两者较小的一个。比如pack(1)，所有成员都按1字节对齐，结构体就变成了紧凑布局。

#include <stdio.h> #include <stdint.h> #include <stddef.h> #pragma pack(push, 1) struct PackedHeader { char version; uint32_t length; uint16_t crc; }; #pragma pack(pop) struct AlignedHeader { char version; uint32_t length; uint16_t crc; }; int main(void) { printf("PackedHeader size = %zu\n", sizeof(struct PackedHeader)); printf("AlignedHeader size = %zu\n", sizeof(struct AlignedHeader)); printf("offsetof length in Packed = %zu\n", offsetof(struct PackedHeader, length)); return 0; }

不用pack时，version在偏移0，length要求4字节对齐，从偏移4开始，crc从偏移8开始，整个结构体12字节。pack(1)之后，version偏移0，length偏移1，crc偏移5，总大小7字节，正好符合手工排列的字节流长度。

写pack时要养成使用push/pop的习惯：

• #pragma pack(push, 1) 把当前pack值压栈，再设新值。
• 定义完结构体后马上# pragma pack(pop)恢复现场。

这样影响范围死死限制在结构体定义之间，不会污染后续代码。

4.2 GCC/Clang的属性写法与MSVC的区别

GCC和Clang除了#pragma pack，还支持用属性直接挂在结构体定义上：

struct GccPacked { char a; uint32_t b; } __attribute__((packed)); struct Aligned16 { char a; uint32_t b; } __attribute__((aligned(16)));

attribute((packed))的效果是强制紧凑排布，sizeof(GccPacked)会是5。attribute((aligned(16)))则是把结构体整体对齐值改成16，总大小也会补齐到16的倍数，主要用于性能敏感场景下的缓存行对齐。

MSVC这边不完全认GCC的属性语法，但#pragma pack是通用的，跨编译器代码优先用#pragma pack。C11标准本身没有提供直接修改结构体对齐的可移植方案，所以工程里常见做法是把“需要紧凑布局的结构体”集中放到一个头文件里，统一用#pragma pack控制。

4.3 什么时候该用pack：三个典型场景

网络协议和文件格式是应用pack最密集的地方。二进制文件头、网络包头、共享内存消息结构，都要求内存布局与磁盘或网络上的字节流一致，不pack没法直接用memcpy去做字段映射。

硬件寄存器映射也必须pack。寄存器区块的地址和位宽是芯片手册写死的，驱动里定义寄存器结构体时如果任由编译器对齐，字段会错位，读写全部失效。

第三个场景是嵌入式设备上追求极致内存节省的时候。几十KB RAM的设备里，一个结构体多出几字节填充都是负担，pack(1)可以压掉全部水分。

但pack绝对不是默认选项。非对齐访问在x86上变慢，在一些RISC架构上会异常，pack后的结构体如果被高频访问，性能损失可能相当明显。我的习惯是：能对就对，必要才pack。

5. 工程里的对齐陷阱与性能取舍

看完规则和工具，最后聊几种我在实际编码和帮别人调试时遇到过的对齐陷阱。这些问题教材里讲得不多，但工程里几乎都会撞上。

5.1 直接把字节流强转成结构体指针

网络协议解析最常见的翻车现场：

char buffer[64]; struct AlignedHeader *h = (struct AlignedHeader *)buffer;

如果AlignedHeader没有pack，header里的length字段按对齐规则被放在了偏移4的位置，而网络字节流的length实际在偏移1的位置，强转后读出来的数据完全是错的。

就算你改成PackedHeader，还要同时处理两个问题：一是buffer的开头地址是不是满足结构体对齐要求，如果buffer只是从某个位置的字节流里偏移出来的，地址可能根本不是4的倍数；二是大小端问题，uint32_t在内存里的字节序和网络字节序不同，还得做字节序转换。所以稳妥的协议解析方式是逐字段手动拷贝，或者用memcpy把每个字段按已知偏移量拷出来，不要用整体强转。

5.2 memcmp比较结构体的隐藏bug

不能直接用==比较结构体，于是有人退而求其次用memcmp：

struct Item1 x = {0}; struct Item1 y = {0}; if (memcmp(&x, &y, sizeof(x)) == 0) { ... }

这个写法在日常测试里往往碰巧正确，但存在隐患：编译器在成员之间或者结构体尾部插入的padding字节，内容不保证被初始化。两个逻辑上完全相等的结构体，padding区域可能残留栈上旧数据，memcmp会把它们当成不相等。虽然x和y都用{0}初始化时，大部分编译器会顺手把padding清零，但一旦成员由赋值语句逐字段写入，padding区域就是完全未知的状态。

正确做法是逐字段比较，或者设计协议时让结构体里根本没有padding（用pack(1)或保证成员对齐值均为1）。

5.3 跨平台和跨编译器的尺寸漂移

同一份结构体代码，在Linux 64位、Windows 64位、32位嵌入式平台上sizeof很可能不同。long和指针的大小变化会拉动整体布局，double在不同32位平台上的对齐值也不一致。所以只要结构体要跨平台传输或者落盘，成员必须用定宽类型：int32_t、uint16_t、uint8_t，并且显式pack(1)。

写跨平台代码时别省这个静态断言：

#include <assert.h> _Static_assert(sizeof(struct PackedHeader) == 7, "PackedHeader size mismatch");

布局一旦不符合预期，编译期直接报错，比运行时解析错乱容易排查得多。

5.4 字段排序与padding优化

当结构体用于大量内存驻留而不是字节流交换时，可以靠字段重排节省空间。把对齐值大的成员往前放，小的往后放，尾部填充会明显减少。对比：

struct BadOrder { char a; double b; char c; }; struct GoodOrder { double b; char a; char c; };

BadOrder里double被char挤到偏移8，末尾又补一个char后还要整体补到24。GoodOrder把double放最前面，两个char在尾部连续排列，总大小只有16，省了8字节。

但这并不代表所有场合都该无脑重排。如果结构体要被并发访问，让高频字段分散在缓存行里可能反而有利；如果结构体要与外部接口对接，更不能为了省内存随意变动字段顺序。优化padding之前，先想清楚结构体的本质是“内存里的数据”还是“字节流协议”。

5.5 性能与空间之间怎么取舍

对齐带来空间浪费，但换来CPU单次访存就能取到完整数据。pack(1)省空间，但代价可能是访问变慢，甚至在某些平台上是灾难。

我的取舍经验只有一句话：结构体如果只在程序内部使用，第一优先是保证对齐、排布合理，不必为了几个字节的padding过度优化；结构体如果用于持久化、网络传输、硬件交互，第一优先是把布局固定下来，该pack就pack，并配合静态断言防止编译器“好心办坏事”。最怕的是同一种结构体既被频繁访问又被硬编码到协议里，前者要求对齐，后者要求紧凑，两头都想占，最后只能拆成两套结构体加转换函数。

真正把对齐当成一个设计维度来对待，而不是撞了坑才去查sizeof，才算是把这部分C语言基础吃透了。下次再看到有人问“为什么这个结构体不是5字节”，你就能直接告诉他：不是编译器疯了，是CPU让它这么长的。