我刚入行写C的时候，遇上过一个特别蠢的bug：两个数组分别存传感器编号和温度值，我在中间插了一条数据，结果编号没跟着动，温度值全线错位。当时的师傅扫了一眼代码，只说了一句：“你缺的是结构体。”
结构体（struct）可能是C语言里最被低估的关键字之一。它做的事，说白了就是把原本八竿子打不着的多个数据硬捆成一个整体。但这背后牵扯三件事：类型定义、变量创建、内存对齐。尤其是内存对齐，很多人写了好几年代码，用sizeof一算结构体大小，结果还是跟直觉对不上。
这篇把结构体从语法到内存布局再到工程实战完整串一遍，适合刚学完指针、正在啃结构的C/C++初学者，也适合写嵌入式、写协议解析但被对齐和序列化坑过的老手。看完你至少能回答三个问题：结构体类型和变量到底有什么区别？为什么sizeof算出来的数总是比字段加起来大？结构体做网络传输时为什么经常出诡异问题？
1. 从“数据打包”看结构体的设计动机与适用边界
1.1 三个散装变量为什么不好用
先回想一下没有结构体的时候，我们要表达一个学生的信息得怎么写：
char name[20]; int age; float score;这三个变量确实能存数据，但它们是散装的。你想给某个函数传一个学生，得func(name, age, score)这样把三个参数挨个递过去。如果学生信息再增加学号、班级、地址，参数列表会爆炸。更难受的是，你无法用一个整体概念去描述“这是一个学生”，这三个变量在语义上是割裂的。
数组倒是可以把数据聚合，但数组要求所有元素类型一致。学生会同时包含整数（年龄）、浮点数（成绩）、字符数组（姓名），用数组根本装不下。
这就是结构体存在的根本理由：把不同类型但逻辑上强相关的数据，打包成一个新的复合类型。它解决的不只是“存数据”，更是“让数据有组织、有名字、有关系”。
1.2 结构体真正发力的场景
我在不同项目里见过结构体的各种用法，总结下来最典型的几类：
- 协议解析：网络报文、串口帧、文件头，通常是一段连续的二进制数据，里面有版本号、长度、校验位、载荷。用结构体定义报文格式，再按字节映射到内存里，是最常见的做法。
- 硬件寄存器映射：嵌入式里经常定义一个结构体，把某个外设的所有寄存器按偏移量排好，然后用volatile指针指向寄存器基地址，直接通过成员访问硬件寄存器。
- 内核和底层数据结构：操作系统里的进程描述符、文件节点、设备对象，几乎全是巨型结构体。以Linux的
cdev为例，字符设备在内核里就靠它来管理。 - 链表、树、队列等数据结构节点：每个节点需要存数据和指向下一个节点的指针，这种自引用结构体是数据结构的基石。
甚至在三菱PLC的GX Works3编程环境里，也有“标签结构体”的概念——把多个相关的软元件标签聚合在一个结构体里统一引用。这说明“数据打包”的思想不只在C语言里成立，任何需要组织数据的场景，最终都会走上这条路。
1.3 结构体和“类”的关系
很多从Java、Python转过来学C的人会问：结构体是不是就是没有方法的类？这个理解方向是对的，但不全对。
C语言没有class关键字，结构体承担了数据聚合的职责。你可以往结构体里塞函数指针，模拟出“方法”的效果，但那只适合特定场合（比如回调、驱动层多态）。更本质的区别在于：类的封装把数据和操作这个数据的函数绑在一起，结构体则只是数据的容器，操作它的函数游离在外。
但反过来说，结构体这种“先描述数据、再定义操作”的思路，恰恰是很多C语言项目保持清晰架构的原因。我在写代码前习惯先把结构体定义好——数据结构定了，逻辑就顺了一半。这个习惯后来带到了所有语言里，非常受用。
2. 类型还是实例？结构体声明与变量创建的语法细节
2.1 struct关键字：声明一个类型，不分配内存
先看最基本的形式：
struct Student { char name[20]; int age; float score; };这里struct Student定义了一个新的数据类型，但此时没有分配任何内存。你定义一个int类型，编译器不会为int本身分配内存；同理，struct Student只是一个模板，告诉编译器“以后遇到这种类型，应该按什么布局去分配内存”。
真正分配内存发生在创建变量时：
struct Student stu1; struct Student stu2 = {"张三", 18, 92.5f};stu1和stu2才是实实在在的变量，它们会在栈上占据内存。很多初学者最容易混淆的就是这一步：类型定义只是画图纸，变量创建才真正开工建房子。
你也可以在定义类型的同时创建变量：
struct Student { char name[20]; int age; float score; } stu1, stu2;这种写法适合“这个类型我只需要这几个变量”的情况。如果不打算给这个结构体起名字，还能写匿名结构体：
struct { int x; int y; } point = {1, 2};匿名结构体无法在别处再创建同类型变量，所以只适合一次性使用的场景，平时不建议这么写。
2.2 typedef 与 struct 的组合：一个经典陷阱
每次都要写struct Student这种形式，很多人觉得啰嗦，于是用typedef起别名：
typedef struct Student { char name[20]; int age; float score; } Student;之后声明变量直接写Student stu1;，少打一个struct，清爽很多。最常见的写法是省略标签：
typedef struct { char name[20]; int age; float score; } Student;匿名的结构体配合typedef，类型名照样能用。但一旦结构体需要自引用——也就是成员里有同类型指针，比如链表节点——匿名typedef就会踩坑：
typedef struct { int data; Node *next; // 错误：此时 Node 还没定义完 } Node;这里Node这个别名要到整个typedef语句结束才生效，而next成员在声明时Node还不存在，编译器直接报错。正确做法是保留标签，并在成员里使用struct Node *next：
typedef struct Node { int data; struct Node *next; } Node;这个坑特别典型。我在刚学链表时被它卡了一下午，后来才明白：标签在声明struct的这一刻就生效了，而typedef别名要等整句话结束才生效。
顺带说一句C++：在C++里struct Node声明之后，Node本身就可以直接当类型名用，不需要struct前缀。所以上面那段代码在C++里写Node *next也能编译通过。C和C++在这个细节上的差异，经常让跨语言开发的人措手不及。
2.3 自引用与不完整类型
链表节点的自引用必须是指针，而不是结构体本身：
struct Node { int data; struct Node *next; // 正确，指针只占固定大小 // struct Node next; // 错误：成员类型未完成，无穷递归，无法计算大小 };原理很好理解：编译器要为一个结构体分配空间，必须知道它所有成员的大小。如果成员里嵌一个同类型的完整结构体，那就变成了“无限套娃”，大小永远算不出来。但指针的大小是确定的（32位下4字节，64位下8字节），所以用指针就不会出问题。
还有一种叫“不完整类型”的声明方式：
struct Node; // 只声明标签，不定义成员 struct Node *head; // 可以使用指针，但不能解引用 struct Node { int data; struct Node *next; };这种方式在两个结构体互相引用时非常有用。比如A结构体里有B的指针，B结构体里有A的指针，总得有一个先声明，不完整类型就是用来打破这个死锁的。
2.4 初始化、赋值与传参
结构体变量可以在定义时初始化，C99之后还支持指定初始化器，不用按成员顺序：
struct Point { int x; int y; }; struct Point p1 = {1, 2}; // 按顺序 struct Point p2 = {.y = 5, .x = 3}; // 指定成员，顺序可打乱 struct Point p3 = p1; // 整体赋值整体赋值这条很多人不知道：只要类型完全相同，结构体可以直接用=赋值，编译器会逐成员拷贝。但这里有隐藏风险——如果结构体里有指针成员，=做的是浅拷贝，两个结构体会指向同一块内存，释放时一不小心就是double free。
结构体传参也有讲究。看这个：
void print_student(struct Student s) { /* ... */ } void print_student_ptr(const struct Student *s) { /* ... */ }传值方式会把整个结构体压栈拷贝一份，结构体越大拷贝开销越大。传指针只拷贝一个地址，开销恒定。大结构体一律用指针传参，加const修饰还能防止被意外修改。这是C语言性能优化的一个基本功，面试经常被问到。
3. 内存对齐的计算法则与CPU读取背后的逻辑
3.1 一个反直觉的结果：sizeof怎么不是字段之和
看这个结构体：
struct Example { char a; // 1字节 int b; // 4字节 char c; // 1字节 };直觉上，1+4+1=6字节。但你在32位编译环境下跑一下sizeof(struct Example)，结果会让你怀疑人生：
printf("%zu\n", sizeof(struct Example)); // 32位下输出 12明明是6字节的数据，编译器非要给它凑成12字节。这中间多出来的6个字节叫填充字节（padding），是编译器为了满足内存对齐规则，在成员之间和结构体末尾悄悄插进去的。
这个现象不是编译器的刁难，而是CPU硬件层面的硬性要求。
3.2 为什么CPU需要对齐：一次内存读取的物理真相
现代CPU读取内存并不是一个字节一个字节地取，而是按**字（word）**为单位取的。32位CPU的字长是4字节，64位CPU的字长是8字节。每次访问内存，CPU都倾向于从“字的整数倍地址”开始读取。
假设一个int变量（4字节）被放到了地址0x03而不是0x04，而CPU按4字节一个字来读，那么这个int就会被拆成两半：前半部分在第一个字里，后半部分在第二个字里。CPU需要做两次内存访问、再把两半拼起来才能拿到完整数据。如果运气不好，某些架构（比如早期的ARM、SPARC）干脆直接触发异常。
这就好比你去停车场停车，每个车位都有标准宽度。一辆车如果横在两个车位中间，不仅自己难受，还会堵住旁边。内存对齐的本质就是：每个“身材不同”的成员，都必须停在符合自己尺寸要求的位置上。
3.3 对齐规则：三条规律加一次推演
在不同编译器和平台上，对齐规则会有细节差异，但总体的三条规律是通用的：
- 每个成员有自己的对齐数，通常是
min(成员自身大小, 编译器默认最大对齐数)。x86-64下，默认最大对齐数一般是8字节。 - 成员的起始偏移量必须是它对齐数的整数倍。不满足就填充字节。
- 结构体的总大小必须是内部最大对齐数的整数倍。末尾不足也要填充。
拿前面的struct Example在32位下推演一遍：
| 成员 | 自身大小 | 对齐数 | 起始偏移 | 占用的字节区间 | 填充情况 |
|---|---|---|---|---|---|
| char a | 1 | 1 | 0 | 0 | 无 |
| int b | 4 | 4 | 4 | 4~7 | 1~3填充3字节 |
| char c | 1 | 1 | 8 | 8 | 无 |
| 结构体末尾对齐到4的倍数 | 总大小9→12 | 9~11填充3字节 |
为什么最后要把9字节补成12字节？因为结构体经常用在数组里。如果第一个struct Example占12字节，下一个就在偏移12处，int b依然落在4字节对齐的位置。如果每个结构体只有9字节，下一个结构体里的int b偏移就是9+1+4=14（按成员内部相对位置算），又不对齐了。给每个结构体补足末尾填充，是为了让数组中的每一个元素都满足对齐约束。
再看看嵌套结构体的对齐。嵌套结构体本身的对齐数，取它内部所有成员中最大的对齐数：
struct Inner { char x; // 对齐数1 double y; // 对齐数8 }; // Inner 的对齐数为8，所以大小是16字节 struct Outer { char a; // 偏移0 struct Inner in; // 对齐数8，偏移必须从8开始 char b; // 偏移24 };Outer中，a占偏移0，in要从偏移8开始，所以1~7是填充；in本身占16字节（x在8，y在16~23），到偏移23结束；b放在偏移24，结构体最终大小25，但Outer的最大对齐数是8，末尾补足为8的倍数——32字节。这类嵌套结构体的大小计算，在笔试和面试里非常常见。
日常验证对齐布局有两个好用的工具：sizeof看总大小，offsetof（来自<stddef.h>）看某个成员在结构体里的偏移量：
#include <stddef.h> printf("%zu\n", offsetof(struct Example, b)); // 输出4如果哪天你发现offsetof(struct Example, b)输出1而不是4，说明你手动改了对齐，回头看看是不是用了#pragma pack。
3.4 字段重排：不花一分钱的优化
既然填充字节是白白浪费的内存，那有没有办法减少浪费？有，而且很符合直觉：把大的成员往前提。
struct Example { int b; // 4字节，偏移0 char a; // 1字节，偏移4 char c; // 1字节，偏移5 }; // 总大小6→补成8字节同样的三个数据，只是调整了声明顺序，结构体大小就从12降到8，省了4个字节。如果结构体数组有10万个元素，这一个调整就省了40万字节。
一般原则是：按成员的对齐数从大到小排列。先放double、指针，再放int、float，最后放char。但要注意，如果这个结构体是用来映射协议报文或寄存器布局的，就不能随便重排——协议要求的字段顺序是硬性的，重排会把报文结构搞乱。所以“按大小降序排列”只适用于自己完全掌控内存布局的场景。
3.5 手动改变对齐：什么时候该用，什么时候别用
有的场景需要强制结构体按1字节对齐，让字段紧挨着放。最典型的就是网络协议解析。TCP/UDP报文头、自定义串口协议，通常要求字段之间没有填充字节，直接逐字节解析。这时可以用：
#pragma pack(push, 1) struct PacketHeader { uint16_t version; uint8_t type; uint32_t length; }; #pragma pack(pop)GCC和Clang下还可以用__attribute__((packed))：
struct PacketHeader { uint16_t version; uint8_t type; uint32_t length; } __attribute__((packed));#pragma pack(1)告诉编译器“这个结构体里的成员按1字节对齐”，说白了就是取消对齐。这样可以保证结构体内存布局和报文字节流完全一致，方便直接把结构体指针强转成char*去收发数据。
但取消对齐是有代价的：
- 性能下降：未对齐的成员可能需要多次内存访问，x86上还凑合，ARM上会非常明显。
- 移植性变差：同样的
packed在不同架构上的行为不完全一致，甚至可能引发编译错误。 - 有风险：某些处理器上访问未对齐地址会直接崩溃。
我的实践经验是：除非有明确的二进制协议或硬件映射需求，否则不要动对齐。就算做协议解析，也要加一些防御性代码，比如用memcpy逐字段读取，而不是粗暴地强转指针。这个细节后面序列化章节还会展开。
4. 结构体的工程实战形态与避坑指南
4.1 链表节点：自引用结构体的落地
链表是结构体最经典的应用之一。先看最基本的单链表节点：
struct Node { int data; struct Node *next; };创建链表的过程无非是堆内存分配和指针连接：
struct Node *head = NULL; struct Node *node = (struct Node *)malloc(sizeof(struct Node)); node->data = 42; node->next = head; head = node;这里node->data等价于(*node).data。箭头运算符就是在结构体指针上取成员，写起来比解引用加圆点简洁得多。
遍历链表的逻辑也很简单：
for (struct Node *cur = head; cur != NULL; cur = cur->next) { printf("%d\n", cur->data); }C++里写链表节点时，可以在结构体里写构造函数、成员函数，但本质布局还是一样：
struct Node { int data; Node *next; Node(int val) : data(val), next(nullptr) {} };结构体配合指针，构成了链表、树、图这些基础数据结构的骨架。理解“节点（数据）+ 指针（关系）”这个组合，比背链表代码重要得多。
4.2 位域：用结构体操作二进制位
如果结构体里的成员只想占几个bit，可以用位域（bit field）：
struct Flags { unsigned int a : 1; // 占1个bit unsigned int b : 3; // 占3个bit unsigned int c : 4; // 占4个bit };位域在硬件寄存器定义里很常用，比如一个状态寄存器的bit0表示使能、bit1~2表示模式、bit3~5表示中断源。用位域定义后，代码里直接flags.b = 2就能操作对应bits，比手写位运算可读性高很多。
但位域有一个大坑：bit位的排列顺序由编译器决定，不同平台可能存在差异。你在x86上定义位域去解析一个网络协议，换到ARM平台很可能整个字段全错位。所以位域只适合操作本机内存里的位结构，不适合做跨平台的数据传输格式。
还有一点，位域成员不能取地址，不能用在offsetof上，也没法直接像普通成员那样用指针引用。
4.3 柔性数组：变长数据的优雅处理
结构体的最后一个成员可以声明成不完整数组类型，这就是C99引入的柔性数组（flexible array member）：
struct Buffer { int len; char data[]; // 柔性数组，不占结构体空间 };注意：data[]没有指定长度，它不占结构体空间，sizeof(struct Buffer)只算len那部分。使用时要自己分配额外空间：
struct Buffer *buf = malloc(sizeof(struct Buffer) + 100); buf->len = 100; memcpy(buf->data, source, 100);这种写法比定长数组灵活，比指针成员少一次内存分配。在网络收包、日志收集这类“头部固定+载荷变长”的场景里非常好用。
4.4 内核cdev结构体：嵌套与包含的艺术
Linux内核里有一个经典结构体cdev，代表一个字符设备。实际驱动代码里，我们通常不会直接使用cdev，而是把它嵌套在自己的设备结构体里：
struct my_device { int id; struct cdev cdev; // 内嵌内核对象 /* 更多私有数据 */ };为什么用嵌套而不是继承？因为C语言没有继承，只能用结构体包含结构体。内核通过container_of宏，可以从cdev指针反推回外层my_device结构体的地址：
struct my_device *dev = container_of(cdev_ptr, struct my_device, cdev);这个思想值得仔细体会：结构体嵌套不是简单的“结构体里有另一个结构体”，而是一种组合与关联的手段。它在很多框架代码里都能见到，比如Linux的list_head被嵌入各种业务结构体，实现一个通用的双向链表。真正的高手用结构体，不只是存业务数据，而是用结构体的布局实现各种巧妙的内存操作。
4.5 序列化与跨平台：三个高频坑
把结构体直接写入文件或发送到网络，是很多项目都会走的捷径，但也最容易踩坑。我总结三个高频问题：
第一，结构体比较不能用==，用memcmp也要小心。C语言没有提供结构体的==运算符，很多人改成memcmp(&a, &b, sizeof(a))。但结构体里的填充字节通常没有初始化，里面是随机值，两个所有字段都相同的结构体，memcmp结果可能不相等。正确做法是逐字段比较，或者先把结构体用memset清零再赋值。
第二，浅拷贝问题。结构体里有指针成员时，整体赋值或memcpy都只是拷贝指针值，两个结构体会共享同一块堆内存。如果在两个地方分别释放，立刻double free。
第三，字节序和类型长度。这是跨平台序列化最隐蔽的坑。不同机器的大小端不同，x86是小端，PowerPC等是大端，htonl、ntohl这些函数就是干这个的。更重要的是，写出跨平台代码时不要用long来定义“长位数数字”。在Windows的64位系统里long是4字节，Linux的64位系统里long是8字节，同一个结构体在两边的内存布局完全不一样。正确做法是使用<stdint.h>里固定宽度的类型：
#include <stdint.h> struct FileRecord { int64_t offset; // 无论什么平台都是8字节 uint32_t length; // 无论什么平台都是4字节 uint16_t crc; };凡是结构体要落盘、要传输、要在不同平台间共享，一律用int32_t、uint64_t这些固定宽度类型。协议或文件格式的字段定义，也要以这些类型为准。
最后分享一个我个人一直在用的习惯：写任何结构体之前，先在纸上把内存布局画出来，标清每个成员的偏移量，再动手写代码。写完用offsetof和sizeof验证一遍，关键结构体甚至加一句静态断言：
_Static_assert(sizeof(struct FileRecord) == 16, "FileRecord size must be 16");这样如果未来有人改了结构体定义，编译器直接报错，比运行时发现数据错位要省心得多。结构体的精髓不只在语法，更在于你对内存布局的控制力和敏感度——这一点，值得所有写C/C++的人花时间琢磨。
