很多人发现一个奇怪现象：结构体里几个char、int加起来明明只有几字节，sizeof一测却大了一截，读写硬件寄存器时数据错位，网络发包时协议对不上——这全是内存对齐与隐式填充在暗中起作用，它是C语言为了适配CPU硬件而定下的底层规则，也是底层开发最容易忽略的隐形坑。
一、为什么必须内存对齐？
CPU并不是按1字节随意读写内存的，大多数架构（ARM、x86、DSP）都要求数据要放在自身大小的整数倍地址上，这就是对齐。
- int（4字节）要放在地址为4的倍数的位置
- short（2字节）要放在地址为2的倍数的位置
- char（1字节）任意位置都可以
如果不对齐，两种后果：
- CPU执行多次内存访问，速度大幅下降
- 硬件直接触发地址异常，程序直接崩溃
为了兼顾效率和安全，编译器会自动在结构体成员之间插入填充字节（Padding），强行让每个成员对齐，这就是结构体“莫名变大”的原因。
二、最直观的填充例子
定义两个成员完全一样、只是顺序不同的结构体，大小天差地别：
#include <stdio.h>
// 顺序混乱
struct Bad {
char a;
int b;
char c;
};
// 顺序规整
struct Good {
char a;
char c;
int b;
};
int main() {
printf("Bad: %zu\n", sizeof(struct Bad)); // 输出 12
printf("Good: %zu\n", sizeof(struct Good)); // 输出 8
}
底层填充过程：
- Bad：char(1) + 填充(3) + int(4) + char(1) + 填充(3) = 12
- Good：char(1) + char(1) + 填充(2) + int(4) = 8
仅仅调整成员顺序，就节省了1/3的内存，这就是对齐规则的直接影响。
三、结构体的收尾填充：整体对齐
结构体不仅成员要对齐，整体大小也必须是最大成员大小的整数倍。
比如最大成员是int（4字节），结构体总大小必须是4的倍数，不够就继续填充。
struct Demo {
char buf[3];
};
sizeof(Demo) = 3，最大成员是1字节，无需填充。
struct Demo2 {
char a;
short b;
};
char(1)+填充(1)+short(2) = 4，刚好是short的2倍，无需额外填充。
四、数组、指针、嵌套结构体的对齐规则
数组对齐
数组整体对齐规则和单个元素一致，数组每个元素都自动满足对齐要求。指针对齐
32位系统指针4字节，按4对齐；64位系统指针8字节，按8对齐。嵌套结构体
嵌套结构体的对齐值，等于它内部最大成员的对齐值，并且整体占用空间会被展开计算。
struct A {
char x;
int y;
};
struct B {
char m;
struct A a;
};
sizeof(struct B) = 1 + 3 + 8 = 12。
五、硬件开发重灾区：指定对齐与 packed
在操作硬件寄存器、网络协议、Flash存储时，绝对不允许编译器自动填充，否则数据布局就会错乱。
这时需要使用编译器扩展，强制关闭填充：
// GCC/Clang 关闭填充
struct Protocol {
char head;
int len;
char crc;
} __attribute__((packed));
sizeof(Protocol) = 1+4+1 = 6，无任何填充。
也可以手动指定对齐值：
// 按2字节对齐
struct Data {
char a;
int b;
} __attribute__((aligned(2)));
风险提醒：packed之后，成员可能处于非对齐地址，在部分ARM、DSP芯片上会直接崩溃，必须逐字节拷贝访问。
六、高效编写结构体的实用技巧
按类型从大到小排列成员
把long、int、指针放前面，short中间，char放最后，最大限度减少填充字节。同类型成员集中放置
避免char、int、char穿插排布，减少编译器插入的填充。协议/硬件结构体必须显式控制对齐
使用packed或aligned，禁止隐式填充，保证内存布局可控。不要假设结构体布局固定
跨平台、跨编译器时对齐规则可能不同，通信与存储优先用逐字节拷贝。
总结
内存对齐不是编译器“多此一举”，而是CPU硬件的硬性要求，填充字节是为了让程序稳定高效运行。
普通应用开发可以不用关心，但在嵌入式、网络协议、二进制存储等场景，对齐规则直接决定程序是否正常工作。
