上一页我们看到结构体在内存里连续排列、各成员有偏移。那为什么要这样'绑'在一起？回到一个没有结构体的世界。

上一节我们说结构体把多个变量打包存放——但打包不是简单堆叠，编译器要按每个字段的'脾气'摆位置。下面看一个具体例子，它在内存里到底长什么样。

自左向右是低地址到高地址；蓝格是字段，橙格是编译器为对齐插入的填充。

前页看到结构体在内存中是一块连续的字节，但悬着一个问题：字段到底是怎么排进去的？是按我写的顺序吗？

前页看到字段顺序会影响结构体轮廓；那些空隙不是随意出现的，而是数据必须从合法边界开始留下的代价。

上一节我们明白了为什么要对齐。这一节落到具体规则——不同字节数的数据，分别要求地址是几的倍数。记住这几条，是读懂 struct 内存布局的钥匙。

编译器把源码中的struct一步步翻译成内存布局与机器码。

用 offsetof 和 sizeof 亲眼看编译器塞了多少填充字节。

原顺序 24 字节含 10 字节填充，重排后只剩 2 字节填充，省了 8 字节。

前面我们掌握了「对齐值 = 内部成员对齐值的最大值」。当一个结构体的字段本身又是一个结构体时，这条规则还成立吗？这就是嵌套对齐要回答的问题。

用一段真实可编译的 C 代码，展示 #pragma pack(1) 如何把结构体压缩到 1 字节对齐，并对比默认布局的差异。

#pragma pack(1) 把对齐系数压成 1，int、double 紧贴前字段；sizeof 从默认 24 缩到 14，但未对齐访问会变慢。

自然对齐跑得快却费内存，指定对齐紧凑却有性能代价——什么时候该牺牲什么？

自然对齐 vs 指定对齐，那是编译器层面的承诺。但硬件认不认账？x86、ARM、ARM64 三种 CPU 的回答完全不同——x86 睁一只眼闭一只眼，ARM64 可要较真。

一个结构体变量在内存中的样子——字段顺序、padding、对齐起点——我们都已经看清。那 `Student s[30]` 这 30 份数据，又是按什么规则在内存里排开的？

横轴为内存地址递增方向。每个结构体占16字节，字段按对齐规则排列，尾填充让下一元素从对齐地址开始。

看 gcc 把 arr[i].y 翻译成什么：基址 + i×sizeof + 字段偏移。

汇编把 arr[i].y 拆成三步：基址 + i×sizeof(Point) + 字段偏移 4。sizeof 和 offsetof 都被编译器烧死成常数 8 和 4。

• ✓字段声明顺序直接决定 padding 数量
• ✓对齐是 CPU 访问单元带来的物理代价
• ✓#pragma pack 用对齐换紧凑，有性能成本
• ✓结构体数组按 sizeof 紧密排布，无指针数组空隙

在 32 位系统自然对齐下，struct { char a; int b; char c; } 占多少字节？

先自己想，再看参考答案。三题分别从回顾、应用、迁移三个层次出发。