结构体这三个字，写过 C 或者 C++ 的人都不陌生，可真要回答“这个结构体占多少字节”“为什么调换两个成员顺序之后 sizeof 就变了”这类问题，能一口答上来的人并不多。我见过不少写了三四年嵌入式代码的人，遇到结构体在内存中的存储方式还是靠试，试出来能用就先用着。这篇东西就是把结构体在内存里到底怎么摆放、内存对齐规则怎么算、结构体指针和普通成员有什么区别、union 和 struct 的内存差异在哪里，一次性理清楚。里面涉及的 sizeof 计算、offsetof 验证、#pragma pack 调整、Keil 调试模式下查看结构体变量这些操作，都会给出可以直接复现的步骤和参数。不管你是刚学 C 语言结构体的新手，还是做了几年想把这部分知识补扎实的老手，都能从里面拿到能用上的东西，尤其是排查跨平台数据结构不一致这类问题上，能少走不少弯路。
1. 结构体内存布局的底层逻辑
1.1 从一次 sizeof 计算结果偏离预期说起
几乎每个学 C 语言的人都有过这样一次经历：定义一个看着很简单的结构体，随手用 sizeof 一量，发现结果比自己加出来的数字大。比如下面这个：
struct A { char a; int b; char c; };很多人第一次的直觉是 1 + 4 + 1 = 6 字节。可真正编译运行一遍，sizeof(struct A) 打印出来是 12。这多出来的 6 个字节既不是编译器算错了，也不是我们数错了，而是编译器按照一套叫做“内存对齐”的规则，在成员之间和结构体末尾插入了一些看不见的填充字节。
这件事看起来小，实际影响却很大。你在自定义通信协议、把结构体直接写进文件、或者跨机器传输二进制数据的时候，如果不知道字节是怎么排的，接收方按自己那套规则解析出来的数据就可能整段错位。我早期做设备通信的时候，就因为没注意发送端和接收端编译器默认对齐值不同，导致解析出来的温度字段一直是个奇怪的负数，查了半天才发现是偏移量对不上。
1.2 内存对齐到底在“对齐”什么
要理解填充字节为什么存在，先得明白 CPU 是怎么从内存里取数的。CPU 并不是一个字节一个字节地搬，而是按机器字长成块读取。32 位机器一次读 4 个字节，64 位机器一次读 8 个字节，总线上的传输也是以这样的块为单位，这个块的大小一般就叫做访问粒度。
假设一个 int 类型的变量，在 32 位平台占 4 字节。如果它正好落在地址 0x1000 上，从 0x1000 到 0x1003 刚好覆盖一个完整的 4 字节块，CPU 一次就能把它取出来。可如果它从 0x1001 开始，就横跨了 0x1000 和 0x1004 两个块，CPU 得读两次，再在内部把高低位拼接起来。代价是访问速度下降，某些精简指令集的架构压根不支持这种访问，会直接抛出一个硬件异常。
拿生活里的类比更好懂：一排储物柜，每个格子正好放下一块砖。你要是把砖压在两格中间的隔板上，管理员就得开两个柜门把两半砖拼一块。所以编译器干脆规定，每个成员都必须从自己“合适”的地址开始放，宁可空着几个字节，也不让一个数据横跨块边界。这就是内存对齐的物理动机。
1.3 决定结构体大小的四条核心规则
摸清规则之后，结构体大小其实是可以手工算出来的。编译器在排布成员时遵循下面这四条规则，基本所有主流编译器都按这个来：
- 每个成员的起始偏移量，必须是这个成员自身对齐值的整数倍，不够就在前面补。
- 结构体自身的对齐值，等于它所有成员对齐值中最大的那个。
- 结构体的总大小，必须是它自身对齐值的整数倍，不够就在末尾补到整数倍。
- 如果成员是数组，按数组元素类型的对齐值算；如果成员是另一个结构体，按那个结构体自己算出来的对齐值算，而不是按它内部某个成员算。
关于各类型的“自身对齐值”，在常见的 32 位和 64 位环境下，char 是 1，short 是 2，int 是 4，float 是 4，double 在 32 位下通常是 4 或者 8（跟编译器和 ABI 有关），指针在 32 位下是 4、64 位下是 8。注意，这个对齐值不一定等于类型的大小，比如 long long 在 32 位下大小是 8，对齐值通常是 4 或者 8，需要看具体 ABI。所以实际项目中，最好让编译器告诉你答案，别只靠背表。
注意：不同编译器、不同目标平台、甚至同一个编译器不同版本，默认对齐值都可能不一样。涉及二进制布局的场景，永远以实测为准。
2. 内存对齐的手工测算与实验验证
2.1 手工测算的四个步骤
结构体大小虽然由编译器决定，但我们完全可以自己先算一遍，这样跑出来对不上时，就知道是哪里出了问题。步骤固定是四步：
- 列出每个成员的类型和对齐值。
- 从偏移 0 开始，逐个成员摆放，每摆一个前先看当前偏移能不能被这个成员的对齐值整除，不能就补到最近的整数倍。
- 摆完所有成员后，得到当前总偏移。
- 取所有成员对齐值里的最大值作为结构体对齐值，把总偏移补到这个对齐值的整数倍，结果就是 sizeof。
这个流程看起来机械，但每一步都有明确的判断标准，所以新手也能算对。真正容易错的是第三步和第四步的区分：很多人算完成员摆布就停了，忘了末尾补齐这一步，于是经常少算 4 到 8 个字节。
2.2 一个完整案例的逐步演算
拿前面那个 struct A 完整走一遍，你就能看清每个填充字节从哪来。
成员们依次是：char a（对齐值 1）、int b（对齐值 4）、char c（对齐值 1）。
当前偏移从 0 开始。放 a，偏移 0 能被 1 整除，a 放在 0，占用 1 字节，当前偏移变成 1。
放 b，b 的对齐值是 4，当前偏移 1 不能被 4 整除，往上补到最近的 4 的倍数，也就是 4。因此偏移 1、2、3 这三个字节成为填充，b 放在偏移 4，占用 4 字节，当前偏移变成 8。
放 c，c 的对齐值是 1，偏移 8 能被 1 整除，c 放在偏移 8，占用 1 字节，当前偏移变成 9。
最后取对齐值最大值 max(1, 4, 1) = 4。总偏移 9 不是 4 的倍数，补到 12。所以 sizeof(struct A) = 12。
填充字节的分布是：偏移 1 到 3 共 3 字节，偏移 9 到 11 共 3 字节，总共 6 个填充字节，加上 6 个有效字节，正好 12。
这里有一个细节值得强调：偏移 9 到 11 那段填充，很多人会误以为它属于 c 的“后面”，实际上它属于结构体末尾的补齐，作用是为了让结构体数组里每个元素的起始地址都能满足对齐要求。想想看，如果 sizeof 是 9，那么数组 a[1] 的起始地址就是 9，b 成员就得从 13 开始，整块错位，对齐好处瞬间没了。末尾补齐就是为了避免这个。
2.3 用 offsetof 和 sizeof 验证布局
光算不够，最好让编译器把真实布局报给你。C 标准库里提供了 offsetof 宏，可以直接拿到成员相对结构体起始地址的偏移，配合 sizeof 就能把整个布局打印出来：
#include <stddef.h> #include <stdio.h> struct A { char a; int b; char c; }; int main(void) { printf("sizeof(struct A) = %zu\n", sizeof(struct A)); printf("offsetof a = %zu\n", offsetof(struct A, a)); printf("offsetof b = %zu\n", offsetof(struct A, b)); printf("offsetof c = %zu\n", offsetof(struct A, c)); return 0; }实测在常见的 gcc x86-64 环境下，输出是 12、0、4、8，和我们手工算的一模一样。在 Keil、IAR 这类嵌入式工具链里也支持 offsetof，只要包含了 stddef.h 就行。这个技巧在排查协议错位时几乎是标配，比肉眼盯着定义猜要靠谱得多。
2.4 调整成员顺序把结构体压小
既然填充是编译器按规则补的，那改变成员的排列顺序，就能大幅改变结构体的大小。把 struct A 里小的成员放到一起，大的成员放前面，效果立竿见影：
struct B { int b; char a; char c; };重新演算一遍：b 放在偏移 0，占 4 字节，当前偏移 4。a 放在偏移 4，占 1 字节，当前偏移 5。c 放在偏移 5，占 1 字节，当前偏移 6。结构体对齐值 max(4, 1, 1) = 4，6 补到 8。所以 sizeof(struct B) = 8，比 struct A 整整少了 4 个字节。
这个优化看似小，放到大规模场景里就不一样了。假设一个网络包结构体要发一百万次，每个包省 4 字节，就是 4MB 的带宽差别。在内存受限的嵌入式环境里，几十个结构体数组每个省几字节，累积下来就可能是几百字节 RAM，对只有几 KB RAM 的单片机来说非常值钱。
但重排有个前提：不能破坏业务语义。结构体成员的顺序有时候是有约定意义的，比如和硬件寄存器映射对应，或者和协议字段对齐。这种时候顺序不能动，只能另想办法，比如用 #pragma pack，或者干脆拆成两个结构体。
2.5 用 pragma pack 强制改变对齐
有些场景下你希望结构体紧凑排列，一个填充字节都不要，比如定义协议帧、写配置文件、和硬件寄存器做映射。这时候就可以用预处理指令让编译器放弃默认对齐，按指定值来：
#pragma pack(push, 1) struct Packed { char a; int b; char c; }; #pragma pack(pop)push 和 pop 是一对，push 把当前对齐设置压栈，pop 恢复，这样可以保证只影响中间那段定义，不污染其他代码。用了 pack(1) 之后，struct Packed 的每个成员都按 1 字节对齐，sizeof 就是 1 + 4 + 1 = 6，一个填充字节都没有。
注意：pack 强制紧凑对齐会牺牲访问速度，也可能在某些平台上触发未对齐访问异常。用它做协议结构体没问题，因为协议数据本来就是按字节读的；但如果是频繁参与计算的变量，谨慎使用。
实践中更常见的做法是，协议结构体用 pack 定义，接收后立刻拷贝到另一个正常对齐的结构体里参与运算。这样既保证了字节布局正确，又不影响计算性能。
3. 结构体指针与链式结构的内存组织
3.1 结构体指针成员的本质是一个地址
很多初学者会把结构体指针和结构体成员混淆。要分清楚：结构体指针变量本身，存的是一个地址，它的大小只取决于平台，32 位下 4 字节，64 位下 8 字节，和它指向的结构体有多大毫无关系。
struct Point { int x; int y; }; struct Point *p;sizeof(p) 在 64 位下是 8，sizeof(struct Point) 是 8，两者凑巧相等，很容易让人误以为相关。换个成员更多的结构体，指针大小依然是 8，这就说明它和指向内容无关。
理解这一点对计算结构体大小很关键。上面那个 struct Point 只有两个 int，对齐值 4，sizeof 是 8。如果结构体里塞一个结构体指针作为成员，这个成员只按指针大小算，不按它指向的内容算。很多人在设计树、链表结构时忘了这一点，算出巨大的结构体，其实是把指针当成了被指对象本身。
3.2 自引用结构体与链表的内存形态
链表节点的定义长这样：
struct Node { int data; struct Node *next; };这里能写成 struct Node *next，是因为指针的大小是确定的，编译器在解析结构体定义时并不需要知道 struct Node 的完整布局，只需要知道这个指针类型存在就行。如果你写成 struct Node next，编译器就会报错，因为它无法在定义自己的过程中知道自己的大小，这会导致无限递归。
真实内存里，每个节点是独立分配的一块内存，通过指针串在一起。节点本身的布局仍然遵循对齐规则：data 在偏移 0，占 4 字节，next 在偏移 8（假设 64 位平台，指针对齐值 8），中间偏移 4 到 7 有 4 个字节的填充。整个节点大小 16 字节。所以链表虽然逻辑上是一条线，物理上却是一堆分散的块用地址串起来的。
链式结构在嵌入式里特别常见，但它有一个隐患：节点分散分配，内存管理器如果产生碎片，时间长了可能申请不到连续内存。我见过一些设备跑几天后链表操作就失败，最后定位到是内存碎片。解决办法之一是用内存池预先分配一大块，自己管理节点，避免频繁的堆分配。
3.3 指针成员和数据成员的内存归属差异
再强调一次区别，这是很多人栽跟头的地方。指针成员留在结构体内部的只是那个地址值，它真正指向的数据一般在堆上、别的地方，不在这个结构体的内存块里。看下面这个：
struct Buffer { int len; char *data; };sizeof(struct Buffer) 在 32 位下是 8：len 占 4，data 指针占 4，没有填充。但如果你以为 sizeof 能涵盖 data 指向的缓冲区大小，那就错了。真正存数据的内存，是 data 指向的另一块空间，得单独管理它的申请和释放。
这个区别直接决定了内存泄露的排查思路：结构体本身好释放，只要把指向的堆内存漏了，照样泄露。所以带指针成员的结构体，释放逻辑一般是先释放内部指针指向的内存，再释放结构体本身。顺序反了，先释放结构体，内部指针就丢了，那部分内存再也没法回收。这点在资源紧张的嵌入式系统里，就是很常见的泄露来源。
4. 结构体、联合体与嵌套的内存差异
4.1 union 的内存复用机制
union 和 struct 长得很像，内存行为完全不同。struct 的成员是并排摆放、各占各的；union 的成员是共享同一块内存，从同一个起始地址开始叠放。所以 union 的大小，取所有成员里最大的那个，同样也要考虑对齐。
union U { int a; char b[5]; };这里成员 a 占 4 字节，成员 b 占 5 字节，最大的成员是 5 字节，union 的对齐值是 4（由来 a 对齐值决定），所以总大小补到 8。结果是 sizeof(union U) = 8。你可以看到，a 和 b 从同一个地址开始，写 a 会覆盖 b 的前 4 个字节。
union 的典型用法是做类型转换和协议解析。比如一个 4 字节的数据，按字节读还是按 int 读，用 union 就不用显式做指针类型转换了：
union Word { unsigned int value; unsigned char bytes[4]; };这种写法在通信解析里很常见，把收到的字节塞进 bytes，直接读 value 就能拿到整数，比位移拼接更直观。注意区别字节序，同一份数据在大端和小端机器上解出来的整数可能不一样，跨平台协议里必须统一字节序，通常约定用大端传输。
4.2 嵌套结构体的布局推算
结构体嵌结构体的情况也很常见，算大小时关键是记住那条规则：嵌套的结构体按它自己算出的对齐值参与外层的排布，而不是按它内部某个成员。看这个例子：
struct Inner { char a; int b; }; struct Outer { char x; struct Inner y; char z; };先算 Inner：a 在偏移 0 占 1 字节，当前偏移 1；b 的对齐值是 4，补到 4，b 占 4 字节，当前偏移 8；Inner 对齐值是 4，8 已是 4 的倍数，所以 sizeof(struct Inner) = 8。
再看 Outer：x 在偏移 0 占 1 字节，当前偏移 1；y 的对齐值是 4（Inner 的对齐值），补到 4，y 占 8 字节，落在偏移 4 到 11，当前偏移 12；z 的对齐值是 1，放在偏移 12，当前偏移 13；Outer 的对齐值取 max(1, 4, 1) = 4，13 补到 16。所以 sizeof(struct Outer) = 16。
注意，嵌套结构体的对齐值可能比它所有成员对齐值都大，如果 Inner 里有个 double，那 Inner 和 Outer 的对齐值都会被拉高。这种连锁效应常见于多层嵌套的协议结构，一层层推下来容易出错，用 offsetof 逐层验证最稳。
4.3 位域的内存排布和陷阱
位域允许你按位定义成员，适合做寄存器映射，能省下大量空间：
struct Flags { unsigned int a : 3; unsigned int b : 5; unsigned int c : 8; };三个成员加起来 16 位，按 4 字节对齐的话，结构体总大小其实是 4 字节。位域在同一存储单元里连续排列，如果累计位数超过一个存储单元，编译器会换到下一个单元，具体行为依赖编译器实现。
位域有几个坑必须说清楚。第一，位域成员不能取地址，因为一位或几位不构成一个可寻址的对象，写 &s.a 会直接编译报错。第二，位域的分配顺序，从低位还是高位开始，C 标准没有统一规定，不同平台可能不同，所以位域结构体不适合直接用于跨平台协议。第三，位域的类型不要填有符号整型，某些编译器对符号位的处理会出人意料，建议统一用 unsigned int。
我个人的习惯是，位域只用在和硬件寄存器打交道的场景，而且对照芯片手册逐位核对；跨平台协议一律用显式字节和移位运算，虽然麻烦点，但绝对不会出字节序或位序的分歧。
5. 常见问题与排查技巧实录
5.1 结构体内存相关问题速查表
排查结构体问题时，我习惯按现象先定位方向，下面这张表整理了几类高频问题，照着对号入座能省不少时间：
| 现象 | 常见原因 | 排查手段 |
|---|---|---|
| sizeof 比预期大 | 内存对齐填充 | 用 offsetof 逐成员确认偏移 |
| 跨平台解析数据错位 | 默认对齐值不同 | 双方都用 pack(1) 统一定义 |
| 结构体数组访问越界 | 忘记末尾补齐 | 校验 sizeof 是否为对齐值整数倍 |
| 指针成员释放后仍访问 | 野指针 | 释放后立刻置 NULL |
| 结构体内存泄露 | 只释放结构体没释放内部指针 | 按“先内后外”顺序释放 |
| 位域解析结果异常 | 位序或符号位实现差异 | 换成显式移位运算 |
这张表不是一次就能记住的，建议在实际调试中不断补充自己遇到的情况，慢慢就形成了自己的经验库。
5.2 Keil 调试模式下查看结构体变量
做嵌入式的人大部分都碰过 Keil，调试时想把结构体展开看每个成员的值，需要一点设置。默认情况下 Keil 的 watch 窗口对结构体是折叠的，加号点开后能看成员。如果你看不到加号或者展开后成员显示灰色，通常是几个原因：一是编译器优化把变量优化没了，解决办法是把这个变量声明成 volatile，或者把优化级别降到 -O0；二是变量被分配在寄存器里，没有内存地址，watch 窗口就看不到；三是结构体定义的头文件没被正确包含，导致调试器不知道成员布局。
有个小技巧我自己经常用：在 watch 窗口里直接输入变量名后跟着成员名，比如node->next->data，这样即使不展开也能直接看某个具体成员。另外，如果结构体带指针成员，watch 窗口显示的指针值是地址，展开它能看到指向的内容，方便跟踪链式结构。
还有个容易忽略的点：调试器的类型信息来自编译产物里的调试符号，所以发布 Release 版本时通常不带调试信息，watch 窗口里看不到结构体成员是正常的。需要调试就切回带 -g 的 Debug 版本。
5.3 跨平台传递结构体的坑
这是结构体内存布局最容易翻车的场景，也是最值得单独聊的一段。当两个平台的结构体定义看起来一样，直接按二进制传，接收方解析出来的数据却对不上，原因通常有三个。
第一个原因是默认对齐值不同。某些架构默认 pack 4，某些是 pack 8，同样的定义出来的大小和偏移都不一样。解决办法只有一条，凡是二进制协议用的结构体，一律用 #pragma pack(push, 1) 包起来，两端都按 1 字节对齐，布局就统一了。
第二个原因是类型大小不同。long 在 32 位平台上是 4 字节，在 64 位平台上是 8 字节，如果你在协议里用了 long，两端就对不上了。协议里应该全部使用明确位宽的类型，比如 int32_t、uint16_t，这样跨平台无歧义。
第三个原因是字节序。大多平台是小端，但有些通信协议规定按大端传。如果发送方按本机内存直接发，接收方按协议解，就会读反。解决办法是在协议层统一字节序，发送前或接收后做一次转换，或者直接用 htonl、ntohl 这类标准函数处理整数。
提示：跨平台协议结构体里，杜绝使用 bool、long、位域、普通 enum，这些在不同平台上的布局都可能有差异，用明确宽度的整型类型最稳。
5.4 fscanf 读结构体时容易踩的坑
有朋友问过 fscanf 读结构体的问题，常见用法是这样：
struct Record { int id; char name[16]; }; FILE *fp = fopen("data.txt", "r"); struct Record r; fscanf(fp, "%d %15s", &r.id, r.name);这里的前提是，fscanf 只是按格式把文本解析后逐字段赋值，它和结构体的内存布局没有任何关系。也就是说，fscanf 不会把整个结构体一次性读进去，而是逐个字段填。所以别指望 fscanf 能直接读二进制结构体，处理二进制要用 fread。
真正容易踩的坑是几个：用 %s 读字符串没有指定宽度，输入超过缓冲区长度就会越界，上面写成 %15s 是为了给 name 的最后一位留出字符串结束符，防止越界。另外，fscanf 的返回值表示成功匹配的字段数，应该检查，否则读失败时结构体里是未初始化值。第三，如果文件里有换行、空白，格式串要对应处理，不然可能读到不该读的内容。
我自己的习惯是先用 fgets 读整行，再用 sscanf 解析到结构体里，这样比 fscanf 更可控，出错也好定位，不容易陷入循环读同一行的坑。
6. 结构体内存优化的几个实用经验
说了这么多规则和排查，最后落到实际工作上，我分享几条踩过坑之后总结的经验。
第一，结构体不要直接用 memcmp 比较。看着两个结构体内容一样，memcmp 返回不一样，八成是填充字节里残留了未初始化的脏数据。正确做法是初始化时用 memset 清零，或者逐字段比较。我在一次单元测试里为这个问题排查了两个小时，最后发现就是填充字节没清干净。
第二，大规模数组优先考虑把结构体的内存占用压到最小的对齐倍数。比如能把 12 字节压成 8 字节的结构体，如果要在 1MB 的内存里放十万个，省下的就是 400KB。做法就是按对齐值从大到小排列成员，末尾自然就不会再补太多。
第三，堆上的结构体和栈上的结构体布局是一样的，区别只在分配位置。栈上的结构体生命期一到就消失，堆上的需要手动管理。带指针成员的结构体尽量别放栈上，不然内部指针指向的堆内存很容易游离，忘记释放。
第四，发送协议数据之前，先在本机做一次自省。可以写个小的自检函数，把 sizeof 和各个成员偏移打印出来，和协议文档逐条对照，一致了再发。这个习惯帮我省下过好几次联调时间，比事后抓包分析快得多。
第五，union 不是万能的省内存手段，它只是复用同一块空间。如果你把一堆成员塞进 union，实际只同时用一个，那确实省；但如果实际上要同时保存多个，union 只会互相覆盖，最后数据全丢。这一点上，struct 和 union 的区别，本质上就是“并肩”和“叠放”的区别。
