你写typedef struct { uint8_t id; uint32_t data; uint16_t crc; } Packet;的时候，大概率觉得这是 7 个字节。毕竟 1+4+2 嘛。
sizeof(Packet)打印出来是 12。
多出来的 5 个字节，是编译器偷偷塞进去的。它没告诉你，也没问你同不同意。这 5 个字节，是嵌入式工程师和"内存"打交道的第一课。这一课的终点不是省几个字节，是怎么用 struct 把整个系统的架构撑起来。
我从业十几年，接手过的祖传项目里，struct 用得好的，代码越改越顺；struct 用得乱的，改一个字段崩三处。这篇文章我想顺着"内存的第一个字节"这条线，从 padding 一路讲到面向对象，把中间那些踩过的坑都摆出来。
sizeof 凭什么不是 7：对齐和填充
先把这个 12 字节的谜题拆开。
typedef struct { uint8_t id; // 1 字节 uint32_t data; // 4 字节 uint16_t crc; // 2 字节 } Packet; // sizeof = 12，不是 7内存里它长这样：
编译器在id后面塞了 3 个字节填充，在crc后面又塞了 2 个。为什么？两条规则：
- 每个成员的起始地址，必须是它自身大小的整数倍。
data是 4 字节，所以它的偏移必须是 4 的倍数。id只占了偏移 0，data没法放在偏移 1，得跳到偏移 4，中间 1-3 就成了 padding。 - 整个结构体的大小，必须是最大成员大小的整数倍。这里最大成员 4 字节，所以总大小得凑成 4 的倍数，12 正好。
这两条规则不是编译器闲得慌。CPU 访问内存，很多架构上一次抓一个对齐的字（32 位机一次 4 字节）。如果data跨在偏移 3-6，CPU 得抓两次再拼，慢一倍；在 Cortex-M0 这类不支持非对齐访问的核上，直接抛异常。
所以对齐是用空间换时间、换稳定性。但嵌入式工程师对空间敏感，RAM 就那么大，5 个字节乘上几千个包，就是几十 KB 的浪费。
省内存的笨办法：把成员从大到小排
最省事的优化，是按成员大小从大到小排列。
// 浪费：sizeof = 12 typedef struct { uint8_t id; uint32_t data; uint16_t crc; } Packet_Bad; // 紧凑：sizeof = 8 typedef struct { uint32_t data; // 偏移 0 uint16_t crc; // 偏移 4 uint8_t id; // 偏移 6，尾部填充 1 字节 } Packet_Good;把data提到最前面，它天然对齐在偏移 0；crc跟在偏移 4，也是 2 的倍数；id在偏移 6。最后凑成 8 字节，只浪费 1 个字节。省了三分之一。
这个写法不需要任何编译器扩展，可移植性最好，是我推荐的首选。代价是字段顺序和"逻辑顺序"不一致。你定义协议时可能习惯先写帧头再写数据，但为了省内存得反过来。这个代价我觉得值，但要在注释里写清楚为什么这么排，不然下一个接手的人会"好心"帮你调回去。
当协议不能动：__packed强制取消对齐
有些场景你没法重排。比如通信协议，帧格式是定死的，对端按字节流解析，你这边 struct 必须和线上格式一字节对一字节。这时候用__packed：
typedef struct __attribute__((packed)) { uint8_t type; uint32_t seq; uint16_t length; } FrameHeader; // sizeof = 7，没有填充packed告诉编译器别塞 padding，严格按定义的顺序紧凑排列。sizeof 变成 7，和协议一致。
但 packed 不是免费的午餐。取消对齐后，CPU 访问seq这个 4 字节成员时，它可能跨在偏移 1-4，CPU 得拆成多次访问再拼，性能下降。更狠的是，在 Cortex-M0、M0+ 这些不支持非对齐访问的核上，访问 packed 结构体的多字节成员会直接触发 HardFault。
我见过一个真实事故：同事在 M0 上用 packed struct 接收串口数据，本地测试好好的，上了产线偶发死机，查了三天才发现是 packed 的非对齐访问在某些数据组合下触发了异常。所以 packed 要用，但只用在你确定会跨字节边界、且确定平台能扛的场景，比如协议帧头这种本来就是字节流的。在能重排的内部数据结构上，老老实实从大到小排，别图省事用 packed。
位域：用 struct 摁住每一个 bit
寄存器是按 bit 算的。一个 GPIO 控制寄存器 32 位，bit0 是使能、bit1 是方向、bit2 是中断使能、bit4-7 是模式。传统写法是位操作：
#define REG (*(volatile uint32_t *)0x40020000) REG |= (1 << 0); // 使能 REG &= ~(1 << 1); // 清方向 REG = (REG & ~(0xF << 4)) | (mode << 4); // 设模式能跑，但读起来像天书，改起来容易漏一个取反。位域让 struct 直接操作 bit：
typedef struct { uint32_t enable : 1; // Bit 0 uint32_t dir : 1; // Bit 1 uint32_t irq_en : 1; // Bit 2 uint32_t mode : 4; // Bit 4-7 uint32_t padding : 24; // Bit 8-31 } GPIO_CtrlReg; volatile GPIO_CtrlReg *ctrl = (GPIO_CtrlReg *)0x40020000; ctrl->enable = 1; // 使能外设 ctrl->mode = 5; // 设置模式可读性高了一个档次。但位域有个坑：位域的内存排列顺序是编译器相关的。先放高位还是低位、是否跨存储单元，C 标准没规定，GCC 和 Keil 可能不一样。所以位域只适合在同一编译器、同一平台下用。一旦你的代码要跨编译器移植，或者要和硬件寄存器的 bit 位置严格对应，位域就靠不住了。这时候老老实实回位操作，丑但确定。
我的习惯：寄存器映射用位域（同平台内，可读性优先），跨平台协议解析绝不用位域。
零拷贝：struct 指针直接怼到缓冲区上
到这里 struct 还只是"装数据的容器"。真正让它变成架构工具的，是零拷贝这一步。
接收一帧数据，传统做法是逐字段拷贝解析：
void on_data_received(uint8_t *buf, uint16_t len) { uint8_t head = buf[0]; uint8_t cmd = buf[1]; uint16_t length = buf[2] | (buf[3] << 8); uint8_t *payload = &buf[4]; // ... 逐字段拷贝到本地变量 }每来一帧都拷一遍，慢，还容易写错偏移。用 struct 指针直接映射：
typedef struct __attribute__((packed)) { uint8_t head; // 帧头 0xAA uint8_t cmd; // 命令字 uint16_t length; // 数据长度 uint8_t payload[]; // 柔性数组，变长数据 } Frame; void on_data_received(uint8_t *buf, uint16_t len) { Frame *frame = (Frame *)buf; // 零拷贝，直接映射 if (frame->head != 0xAA) return; process_payload(frame->payload, frame->length); }把缓冲区指针直接 cast 成 struct 指针，成员访问就是按偏移读内存，一次拷贝都没有。变长数据用柔性数组payload[]挂在末尾，长度由length字段决定。
这个写法快，但有两个前提必须满足。第一，struct 必须 packed，否则 padding 会让偏移和线上字节对不上。第二，字节序要对得上，length是大端还是小端，得和发送方一致，跨端设备用ntohs/htons转一下。还有个容易忘的：别用零拷贝的 struct 指针去修改 buf。如果 buf 是 DMA 接收缓冲区，改了可能和下一次接收撞车。
零拷贝是 struct 从"数据容器"走向"协议抽象"的第一步。到这一步，struct 不再被动装东西，它开始主动定义"数据长什么样"的契约。
struct + 函数指针：C 语言的面向对象
最后一步，也是架构设计的落点。当 struct 既能定义数据布局，又能挂上操作这些数据的函数，它就变成了一个"对象"。
typedef struct { const char *name; int (*init)(void); int (*read)(uint32_t addr, uint8_t *buf, uint32_t len); int (*write)(uint32_t addr, const uint8_t *buf, uint32_t len); int (*erase)(uint32_t addr, uint32_t len); } StorageDevice; const StorageDevice spi_flash = { .name = "W25Q128", .init = spi_flash_init, .read = spi_flash_read, .write = spi_flash_write, .erase = spi_flash_erase, }; void save_config(const StorageDevice *dev, Config *cfg) { dev->erase(CFG_ADDR, sizeof(Config)); dev->write(CFG_ADDR, (uint8_t *)cfg, sizeof(Config)); }save_config不关心底层是 SPI Flash 还是 SD 卡。它只认StorageDevice这个接口：有 init、有 read、有 write、有 erase。换存储介质，只需要换一个实例，把函数指针指向新的实现，上层代码一个字都不用改。
这就是 C 语言的面向对象，也是 Linux 驱动模型、RT-Thread 设备框架、HAL 层的核心套路。到这一步 struct 已经不只是内存布局了，它成了一份接口契约：数据怎么放、能做什么操作，都封装在一起。上层依赖抽象，不依赖具体实现。
回过头看这条线：padding 让你理解内存为什么有空洞，从大到小排列让你主动去填那些空洞，packed 让你在协议约束下妥协，位域让你精细到每一个 bit，零拷贝让 struct 开始定义数据的契约。最后函数指针这一步，struct 连行为也一起封装了。每一步都是在用 struct 这一个工具，把内存里的字节一步步抽象成系统里的架构。
架构设计的本质，我越来越觉得不是画那些花哨的分层图，是把这种"用数据结构封装变化"的能力练成本能。一个 struct 定义得好，硬件变了只换实例，协议变了只改布局，平台变了只调对齐。变化被关在 struct 里面，外面风平浪静。
这也是为什么我接手项目，第一件事是 grep 所有的 struct 定义，而不是先翻 main 函数。struct 长什么样，这个项目的骨架就长什么样。
写到这里，你下次定义 struct 的时候，大概会多想一秒：这个字段顺序省内存吗？这个结构体要不要 packed？它能不能挂上函数指针变成接口？多想这一秒，你就从"写功能"往"设计系统"挪了一步。
嵌入式这一行，真正卡住人的不是语法，是把底层细节一步步抽象成架构的能力。struct 是个特别好的练手场，小到一个上午就能摸透，深的地方能一路通到整个系统的设计。
有用的话点个赞收藏，让更多工程师看到。你项目里有没有那种"改一个字段崩三处"的祖传 struct？评论区聊聊，我猜不止我一个人遇到过。
