你辛辛苦苦写了一个 struct，看着手里的代码：一个 char、一个 int、一个 char，手工一加是 6 个字节，sizeof却不声不响地告诉你 12。这种差别不是编译器魔怔了，而是 C 语言从诞生起就带在身上的“硬件对齐洁癖”在起作用。这篇东西我不打算从头讲一遍教科书，而是直接拿结构体大小计算这件事，把背后的内存对齐规则、为什么是这样、怎么在代码里灵活调整都掰开揉碎，最后把实际开发中容易踩的坑也一并列出来。

适合谁看？平时写单文件程序感觉不到结构体大小变化的人，去搞嵌入式、网络协议、序列化、底层缓存优化的人，以及被这个伸手就能问到的面试题卡住过的人。看完之后你自己就能算出一个复杂嵌套结构体在任意平台上的占用尺寸，而不是只会背“偏移地址要对齐”这句话。

1. 内存对齐：先搞明白是谁在给结构体“塞海绵”

1.1 为什么 CPU 不喜欢“串着读”数据

现代 CPU 和内存打交道的时候，不是一字节一字节单独读的，而是按“字”批量拉取。32 位 CPU 一个周期能读 4 字节，地址往往是 4 的倍数；64 位 CPU 一个周期能读 8 字节，地址往往是 8 的倍数。如果 int 恰好被放到了 4 的倍数地址上，CPU 一次性就能把完整的 32 位数据取走；如果 int 从地址 1 开始，那么它的一部分在地址 1~3，另一部分在地址 4~7，CPU 不得不先取前半段、再取后半段，最后拼成一个完整的 int 返回给你，一来一回性能直接打折。

x86 架构成熟之后做了很多容忍措施，非对齐访问也能给你一个正确结果，只是慢。但在一些 RISC 架构上，非对齐访问直接触发异常，连结果都懒得给你。所以 C 编译器为了给绝大多数平台生成安全且高效的代码，会默认给每个变量布置一个“偏爱地址”：char 哪都能去，short 偏爱偶数地址，int 偏爱能被 4 整除的地址，double 偏爱能被 8 整除的地址。

1.2 struct 里的空白补位就是从这里来的

单个变量的时候，编译器很容易让变量的起始地址满足对齐要求，因为可以直接把它放在栈上对应的位置。但一旦把这好几个变量捆成一个结构体，就不能自由安排了：结构体里必须是连续的一块内存，成员按声明顺序依次放置。为了给每个成员都凑出满足对齐条件的起始地址，编译器只能在成员之间硬塞一些永远不会被使用的字节，这些字节就是 padding。

一个直观的例子，定义一个最简单的结构体：

#include <stdio.h> #include <stddef.h> struct Demo { char a; // 偏移 0 int b; // 需要 4 的倍数偏移，所以从 4 开始 char c; // 偏移 8 }; int main(void) { printf("sizeof(struct Demo) = %zu\n", sizeof(struct Demo)); printf("offsetof(a) = %zu\n", offsetof(struct Demo, a)); printf("offsetof(b) = %zu\n", offsetof(struct Demo, b)); printf("offsetof(c) = %zu\n", offsetof(struct Demo, c)); return 0; }

在常见的 32/64 位环境上输出是：

sizeof(struct Demo) = 12 offsetof(a) = 0 offsetof(b) = 4 offsetof(c) = 8

注意看，b前面只有 4 个字节，但b的实际偏移是 4，说明a后面被塞了 3 个填充字节。c做完之后整个结构体还需要 3 个字节补齐，不然下一轮分配完全相同的结构体时，第二个结构体的地址就无法保持对齐了。最后整个结构体占 12 字节，而不是 6 字节，这就是结构体大小的第一课。

2. 结构体大小计算的完整规则：三条法则走天下

2.1 每个成员都有自己的“对齐值”

先记一张基础表。C11 里提供了一个操作符_Alignof，GCC、Clang、MSVC 都支持_Alignof(类型)或者alignof(类型)，可以获取某个类型的对齐要求。常见的默认对齐值如下：

不同平台、不同编译器对long和指针的对齐值有差异，这是后面所有陷阱的根源。但计算结构体大小时，你不用把每个类型都背下来，只要牢记“成员起始地址必须是它自身对齐值的整数倍”。

2.2 三条规则，记住它们就足够了

默认情况下（没有人为修改对齐方式），C 编译器算结构体大小会按下面三个步骤走：

1. 结构体的整体对齐值 = 内部所有成员中最大的那个对齐值，但会被默认对齐限制兜住。大部分桌面平台上默认对齐是 8 字节，所以即便你有一个double成员，对齐值就是 8；如果整个结构体最大成员对齐也不到 8，那就取最大成员对齐。
2. 放置每个成员时，先把当前偏移“向上取整”到该成员对齐值的倍数，这个取整过程中空出来的位置全部是填充字节。
3. 所有成员放完之后，再把结构体的总大小向上取整为结构体对齐值的倍数。

这条规则可以理解为“先满足个人需求，再满足团队整体需求”。每个成员都要求地址好看，整体则要求一整块结构体的起点也好看，这样连续两个结构体排在一起时，第二个结构体的起点同样合法。

2.3 手把手推导：朴素例子里面的数学

还是用那个 12 字节的例子走一遍完整流程。struct Demo { char a; int b; char c; };，假设结构体对齐值为 4（因为这个结构体里没有超过 4 字节的类型）。

• a放偏移 0，占 1 字节。
• b的偏移当前是 1，不是 4 的倍数，向上取整到 4。所以填充 3 字节，b放在偏移 4~7，占用 4 字节。
• 现在偏移变成 8，放c，占 1 字节，偏移变成 9。
• 整个结构体目前用到 0~8，总共 9 字节。结构体对齐值为 4，9 不是 4 的倍数，因此向上取整到 12，填充最后 3 字节。

最终sizeof就是 12。同样的 3 个成员，如果调整一下顺序：

struct Demo2 { char a; char c; int b; };

推演一下：

• a在 0，c在 1。
• b偏移当前是 2，不是 4 的倍数，填充 2 字节到偏移 4，占 4 字节，结束偏移 8。
• 结构体对齐值 4，总大小 8，已经是 4 的倍数，不用再补。

这个优化后的版本直接省了 4 字节。到这里你会发现，结构体大小其实就是一个“逐成员放置 + 尾部补齐”的算术题，完全没有魔法。

再做一道稍复杂的题，加深印象：

struct Demo3 { char a; double b; char c; };

在 64 位 Linux 上，double对齐 8。过程：

• a在 0。
• b的偏移当前是 1，不是 8 的倍数，填充 7 字节到 8，占 8 字节，结束偏移 16。
• c在 16，结束偏移 17。
• 结构体对齐值 8，总大小向上取整到 24。

如果调一下顺序：

struct Demo4 { double b; char a; char c; };

过程：

• b在 0，占 8 字节。
• a在 8，c在 9，结束偏移 10。
• 结构体对齐值 8，总大小向上取整到 16。

同样的三个字段，16 和 24 的差距直接翻了一倍。这也就带出了实际开发里最常用的优化手法：重新排列成员顺序。

3. 想省内存，先学会跟编译器谈条件

3.1 排列顺序：把对齐值大的成员往前放

前面已经看到了排序的巨大效果，把大对齐成员放在前面，后面的小成员可以贴着尾巴无缝放置，整段的填充会减少很多。为什么？因为大对齐成员本身需要的起始地址苛刻，把它放开头，它的起始地址天然满足；后面小对齐成员再放的时候，几乎不需要额外填充。

一个常见的安全实践是：按照成员对齐值从大到小排序，从double、指针、long long往下排到char。比如下面这个结构体：

struct ServerConfig { char name[32]; // 1 对齐 int worker_count; // 4 对齐 long long total_requests; // 8 对齐 };

name[32]占据 0~31 后，worker_count必须从偏移 32 开始，没有填充；total_requests从 40 开始，并且结构体尾部补到 48 结束。如果把total_requests提到最前面：

struct ServerConfigOptimized { long long total_requests; // 0~7 int worker_count; // 8~11 char name[32]; // 12~43 // 总大小补到 48，因为 44 刚好不是 8 的倍数 };

这个例子更微妙：把大类型放前面之后，name[32]结束在偏移 44，但结构体对齐值是 8，44 要补到 48，并没有节省太多。所以不能光背“大放前面”这句话，要按规则重算。真正省内存的原则是减少成员之间的“错位空隙”，大对齐成员放前面能消除最刺眼的几段填充，但不代表任何时候都绝对最优。最稳妥的办法就是把几个候选排法用sizeof打个表，一测便知。

3.2 位域：把字节里的零碎空间利用起来

嵌入式开发里，常常会遇到一堆只占 1~3 位的状态开关，如果全部用独立unsigned char字段保存，8 个开关就白白吃掉 8 字节。C 语言提供了位域，让你按位声明成员：

struct Flags { unsigned int readable : 1; unsigned int writable : 1; unsigned int executable : 1; unsigned int reserved : 5; };

readable、writable、executable各占 1 位，reserved占 5 位，合起来刚好占满 1 个字节。但要注意，位域分配的基本单位通常是一个unsigned int（也有可能是其他类型，取决于编译器），所以上面这个Flags实际sizeof很可能是 4，因为编译器按一个 int 单元来切分。不过比特位本身是紧凑的，在这一个unsigned int里，8 位全用上了；如果后续再增加位域成员，只要总位数不超过 32，还会往这个单元里塞，直到塞不下才开启下一个单元。

位域虽然省内存，但也有明显的短板。位域在内存里的排列方向完全由编译器决定，是大端还是小端先分配低位，没有一个统一的标准；同样的一份结构体在不同编译器上甚至可能给出不同布局。所以位域只适合在同一个工具链、短生命周期数据里使用，比如设备寄存器映射、内部报文标记，不适合做跨平台持久化文件头或者网络协议格式。

3.3#pragma pack与__attribute__((packed))：必要时按字节贴死

有些场景天生不适合默认对齐。比如你读一个磁盘上的文件头，或者从一个带固定字段的网络数据包里提数据，里面每个字段都是密集排列的，不允许编译器擅自填充。这个时候可以用打包指令：

#pragma pack(push, 1) struct PacketHeader { uint16_t type; uint32_t length; uint8_t flags; }; #pragma pack(pop)

pack(push, 1)会把后面结构体的对齐要求压到 1 字节，所有成员之间都不允许多余填充；pack(pop)再恢复原来的设置，只影响这一段声明。上面的PacketHeader大小就是 2 + 4 + 1 = 7，干净利落。使用 GCC/GCC 兼容编译器的话，也可以直接在结构体定义后面加：

struct PacketHeader { uint16_t type; uint32_t length; uint8_t flags; } __attribute__((packed));

效果一样。但是，天下没有白吃的午餐：你省掉的填充字节，要么在外面访问未对齐成员时付出性能代价，要么在 ARM 上直接触发总线错误。用pack之前先想想，这段数据是真的需要按字节对齐，还是仅仅因为你不耐烦看那几行 padding。如果你只是为了“看着整齐”把整个结构体都打成 1 字节对齐，后期性能跑起来再哭着改回去，这坑我见过好几次。

4. 遇到数组、嵌套结构体、联合体怎么继续算

4.1 数组成员：按元素类型整体算

结构体里放数组非常常见，但数组不会让对齐规则变复杂。数组的整体对齐值就是元素类型对齐值，数组的总字节数是元素大小乘元素个数。比如：

struct BufferedRecord { char prefix; int values[3]; };

计算过程：

• prefix放在 0。
• values[3]的元素是int，对齐值 4。当前偏移 1 需要补 3 字节到 4，所以values从偏移 4 开始，占 12 字节，结束偏移 16。
• 结构体对齐值 4，总大小 16，结束刚好是 4 的倍数，不用再补。

如果数组里是double values[3]，对齐值变为 8，前一步的补齐就是 7 字节，最后总大小也向 8 对齐。规则没有变，只是把数组中每一个元素的齐整性压缩到了“成员级”。

4.2 嵌套结构体：把内层结构体当成一个可变大小的大成员

嵌套结构体是最容易让人头脑发热的地方，很多人傻傻地把内层总大小直接相加，结果完全对不上。正确的思路是：内层结构体对整个外层暴露一个“固有的对齐值”，这个对齐值取决于它内部最大成员的天然对齐要求，而不是它自己的sizeof。

看这个例子：

struct Inner { char a; double b; char c; }; // sizeof = 24，对齐值 8 struct Outer { char first; struct Inner inner; char last; };

怎么算？

• first在偏移 0。
• Inner的对齐值是 8（因为内部有 double），所以inner的起始偏移必须 8 的倍数。当前偏移 1，补齐 7 字节到 8。
• Inner自身占 24 字节，结束偏移 32。
• last在 32，结束偏移 33。
• Outer的整体对齐值也是 8，33 向上取整到 40。

最后sizeof(Outer)是 40。你可以看到，内层结构体不仅在外层里占位，还把内部自己补的那 3 个尾巴字节也带进去了，再加上外层为了让内层开头对齐而补的 7 个字节，外层消费者感受到的体积比两个结构体单独算要多一截。处理嵌套结构体时，一定要先算内层结构体的对齐值和大小，再把它当作一个整体摆到外层里去，别一层层只加sizeof就完事。

4.3 联合体：取最大成员，但要照顾对齐

联合体的大小算法比结构体简单一些：所有成员共享同一段起始地址，所以空间的最高需求就是最大的那个成员。同时，联合体的对齐值等于所有成员中最大的对齐值。

union Value { char c; int i; double d; };

sizeof(Value)在大多数 64 位系统上是 8，因为最大的double是 8 字节，而 8 也正好是 8 的倍数，直接满足对齐要求。sizeof取 12 的情况也不少见，比如成员里有char buf[10]和一个int，char buf[10]占 10 字节，但联合体对齐值是 4，总大小需要补到 12。再比如：

union Weird { char bytes[13]; int word; // 需要 4 对齐 double dbl; // 需要 8 对齐 };

bytes[13]本身对齐 1，word引入 4，dbl引入 8，所以联合体对齐值变成 8；最大成员 13 字节，向上取整到 16，所以sizeof(Weird)是 16。

联合体塞进结构体时，仍然套用前面的规则，把联合体当作一个大成员，它的起始偏移必须满足联合体对齐值，它占的字节数就是它的sizeof。

4.4 柔性数组：C99 里那个“挂在结构体尾巴上”的洞

最后说一下柔性数组。C99 允许结构体的最后一个成员是“不完全数组类型”，也就是数组大小留空：

struct Flexible { int length; char data[]; };

这种结构体的妙处在于，data不参与计算sizeof。sizeof(struct Flexible)在 64 位环境下通常是 4（因为length占 4，最后再补到 4 的倍数）。创建实例时，你可以手动分配一块比sizeof(struct Flexible)更大的内存，然后在data上访问扩展出来的字节：

size_t cap = 128; struct Flexible *p = malloc(sizeof(struct Flexible) + cap); p->length = cap;

data的偏移正好等于offsetof(struct Flexible, data)，你可以在运行时决定结构体的实际可用空间，而不是写死数组尺寸。这在嵌入式协议栈、序列化缓冲区里非常实用，也比老的“长度为 1 的 hack”在标准层面更安全。注意，柔性数组必须放在最后一个位置，并且不能中间嵌着别的东西；有些老的代码用data[0]模拟柔性数组，但那是 GNU 扩展或编译器兼容行为，新项目直接写data[]就好。

5. 跨平台、性能与疑难杂症：这些坑是真的坑

5.1 为什么同一个结构体在不同系统上大小差一截

同一个代码在两个环境编译，sizeof却不一样，十个里有八个是对齐值和基础类型宽度导致的。最典型的是long：在 64 位 Linux（LP64 模型）里long占 8 字节、对齐 8，在 64 位 Windows（LLP64 模型）里long占 4 字节、对齐 4。成员里有long的结构体，两边算出来必然不一样。

另外，32 位系统上的指针是 4 字节、对齐 4，64 位系统上的指针是 8 字节、对齐 8。一个结构体如果有指针成员，在 32/64 位版本之间迁移时大小也会变化。跨平台交换二进制数据时，不要直接用sizeof去读文件、写网络包，而应该用固定宽度类型：uint32_t、int64_t、uint16_t，再配合pack或者把一个平台下计算好的偏移量写进宏里。最保险的做法是，在结构体定义旁边写一个静态断言：

#include <stddef.h> #include <stdint.h> struct FixedHeader { uint32_t magic; uint16_t version; uint16_t count; }; _Static_assert(sizeof(struct FixedHeader) == 8, "Header layout changed!");

一旦某天某编译器把这个结构体的布局改了，编译期直接报错，总比线上运行时解析错乱好。

5.2 别小看那几个填充字节：批量分配时的内存账单

一个结构体多 4 字节，听起来无所谓。但如果你的服务进程里缓存了一百万个这样的结构体呢？4 字节乘以 100 万就是 4MB。放到嵌入式系统里，SRAM 总共 128KB，多出来的 20% 可能直接让固件启动崩溃。我在一个小型边缘设备上见过一个节点对象，原本成员排序比较随意，32 字节的数据结构被编译器排成了 40 字节，只影响 5000 个节点的表，就多了 40KB。把成员按对齐从大到小排一遍，立刻从 40 掉回 32，表也机动了。那不是玄学，就是两条规则而已。

当然，优化结构体布局的时候要看使用场景。如果这个对象在动态表里长期存活，内存占用就得抠；如果只是函数栈上的临时变量，生命周期极短，就不用为了几个字节把代码可读性折腾坏。

5.3 多线程高频访问：缓存行对齐带来的隐藏加速

对齐不只有“省内存”这一面，有时候反而是“多占用”更有价值。现代 CPU 从内存读数据时，以缓存行（通常 64 字节）为最小单位整块搬运；多个线程如果各自频繁修改同一缓存行里的不同变量，它们之间会互相踢掉缓存行，性能雪崩。这种问题叫伪共享。

解决办法之一，就是让某些高频使用的独立变量不在同一个 64 字节窗口里。可以用aligned属性显式把结构体或者成员按 64 字节对齐：

struct ThreadStat { unsigned long count; } __attribute__((aligned(64)));

这样结构体实例的起始地址固定在 64 字节边界上，单个实例内部不会混入其他线程的数据。__attribute__((aligned(64)))是 GCC/Clang 风格；C11 语法则更通用些：

struct _Alignas(64) ThreadStat { unsigned long count; };

这样做的代价是每个实例都会占满 64 字节甚至更多（因为要对齐），但换来了多线程场景下的确定性。适合一个线程一个实例的高频计数器。你别在普通业务结构体上乱套aligned(64)，否则你会发现一个 8 字节的小对象被放大成 64 字节，又反过来骂 C 浪费内存。

5.4 实战排查：用工具把布局当场照出来

遇到任何拿不准的结构体布局，我都建议先输出一下，而不是靠猜。最直接的方法就是用offsetof和sizeof把这些值打到日志里，后面每一个字段都对得上号之后，再做下一步。对于 Linux 开发环境，还有一个叫pahole的调试符工具，可以直接解析 DWARF 调试信息，把结构体里每个成员的偏移和 padding 情况按行列出来。不过一般项目里没必要特意装它，手写几个printf足够。

我之前调一个协议模块，开发机上结构体大小是 28，部署到 32 位目标机上变成 20，数据读出来全是错位。最后就是用offsetof把那几个关键成员偏移一打，发现目标机的long long对齐值只有 4，某个uint64_t字段被塞到了偏移 12 而不是 16。查到这一步直接换用打包定义，问题解决。所以请把offsetof当成调试结构体布局的第一工具，它准确、可控、跨编译器一致。

6. 最后分享几条实战心得

我在实际项目里处理结构体布局，最常用的动作就三个：先写代码声明成员，再按对齐重新排一次序，最后用sizeof和offsetof验证一遍。排完序不代表一定最优，但几乎不会比原来更差，尤其当成员里同时有指针、double、long long和一堆char数组时，大对齐成员放前面通常是稳赚不赔的。

第二个心得是：不要为了“多省那几十字节”把整个结构体无脑打成pack(1)。如果数据需要长期驻留内存、频繁读改写，默认对齐远比“紧凑”重要。如果需要传输、落盘，那就严格控制固定宽度类型，并在编译期做静态断言，确保两端布局一致。这两种诉求走两条路线，不要混着来。

第三个心得比较实际：读代码时别只看sizeof，要留意 offset。两个看起来一模一样的结构体，成员顺序不同，偏移完全不同；你用“首地址偏移 + 成员类型长度”的方式去操作结构体，才是真正在理解 C 的内存模型。

最后再说一个调试小技巧：如果你在某平台发现结构体大小和预期不一致，优先检查默认对齐值和指针宽度，然后考虑是不是有double或long long参与了布局。只要把这两个变量列出来，90% 的结构体大小难题都当场破案。