📚 课程目录第4章指针与结构体

4、指针与结构体：结构体指针、指向结构体的指针成员、嵌套结构体、结构体数组与指针、内存对齐与填充

在嵌入式C开发中，结构体是组织复杂数据的第一选择，而指针则是实现高效数据操作与动态内存管理的核心工具。当两者结合时，既能构建出灵活的链表、队列、协议帧解析器等基础设施，也引入了指针悬挂、内存碎片、结构体拷贝开销、以及因内存对齐导致的隐性空间浪费等风险。本章将系统拆解结构体指针的运算规则、指针成员的深拷贝与浅拷贝陷阱、嵌套结构体的内存布局、结构体数组与指针的等价关系，以及内存对齐与填充对硬件寄存器映射和通信协议打包的深远影响。

4.1 结构体指针：访问、运算与传参

核心原理：结构体指针本质上是一个保存结构体首地址的变量，其类型决定了指针算术的步长。在嵌入式环境中，结构体指针常用于避免大结构体的值传递开销、实现函数对结构体内容的直接修改，以及构建动态数据结构（如链表）。通过 pStruct->member 或 (*pStruct).member 两种等价方式访问成员，前者是后者的语法糖。

判断方法与操作流程：当需要判断是否应使用结构体指针时，遵循以下准则：

若结构体大小超过 8 字节且函数只需读取，优先传 const 指针，避免栈溢出。
若函数需要修改结构体内容，必须传非 const 指针。
若结构体需要动态分配（malloc/free），则必须使用指针。

指针运算时，p + 1 实际移动 sizeof(StructType) 个字节，而非 1 个字节。这在遍历结构体数组时尤为关键。

实战场景：在 CAN 总线驱动中，通常将报文封装为结构体，并通过指针传递给解析函数。

typedef struct {
    uint32_t id;
    uint8_t  dlc;
    uint8_t  data[8];
} CanFrame_t;

void Can_ParseFrame(CanFrame_t *pFrame) {
    // 直接操作原结构体，避免拷贝 16 字节
    if (pFrame->id & 0x80000000) {
        pFrame->dlc = (pFrame->dlc > 8) ? 8 : pFrame->dlc;
    }
}
// 调用：Can_ParseFrame(&rxFrame);

常见误区：对空指针 NULL 直接解引用会导致硬件异常（HardFault）。在嵌入式裸机环境中，务必在函数入口检查 pFrame != NULL。此外，不要对结构体指针进行 ++ 或 -- 操作，除非明确知道其指向数组中的某个元素。

4.2 指向结构体的指针成员：浅拷贝与深拷贝

核心原理：结构体成员本身可以是指针，这为变长数据（如协议负载）提供了灵活性。但这也引入了所有权问题：当结构体被复制时，默认执行浅拷贝——即只复制指针值，不复制指针指向的数据。这会导致两个结构体指向同一块堆内存，若其中一个释放了该内存，另一个便成为悬挂指针。

操作流程：实现深拷贝需要手动分配新内存并复制数据：

为目标结构体的指针成员分配足够的内存（malloc）。
使用 memcpy 将源数据复制到新内存。
更新目标结构体的长度字段。
释放旧内存（若存在）以避免泄漏。

操作类型	代码示例	内存结果	风险等级
浅拷贝	`Msg_t b = a;`	a.payload 与 b.payload 指向同一地址	高（双重释放/悬挂）
深拷贝	`b.payload = malloc(a.len); memcpy(b.payload, a.payload, a.len);`	两块独立内存	低（需管理释放）
指针赋值	`b.payload = a.payload;`	共享数据，但无所有权转移	中（需约定生命周期）

经验提醒：在嵌入式系统中，优先使用静态分配的固定大小数组（如 uint8_t payload[64]）替代指针成员，以避免堆碎片化。若必须使用指针成员，建议实现引用计数或明确指定“谁分配谁释放”的所有权规则。

4.3 嵌套结构体与内存布局

核心原理：嵌套结构体是指一个结构体包含另一个结构体类型的成员。在内存中，内层结构体的成员会被展开并按照外层结构体的对齐规则排列。访问嵌套成员使用连续的点操作符（如 line.p.x），若通过指针访问则使用 pLine->p.x。

判断方法：计算嵌套结构体大小时，不能简单相加。例如：

typedef struct { uint8_t x; uint8_t y; } Point_t;   // sizeof = 2
typedef struct { Point_t p; uint32_t color; } Pixel_t; // sizeof = 8 而非 6

因为 color 需要 4 字节对齐，编译器会在 p 之后填充 2 个字节。这种填充在硬件寄存器映射中必须显式处理，否则会导致寄存器地址错位。

实战场景：在嵌入式 GUI 中，使用嵌套结构体描述图形对象。

typedef struct {
    int16_t x;
    int16_t y;
} Point_t;

typedef struct {
    Point_t topLeft;
    Point_t bottomRight;
    uint8_t borderWidth;
    uint8_t fillColor;
} Rect_t;

Rect_t rect = {{10, 20}, {100, 80}, 2, 0x1F};
// 访问：rect.topLeft.x = 10;
// 指针访问：Rect_t *pRect = &rect; pRect->bottomRight.y = 80;

风险说明：当嵌套结构体包含指针成员时，深拷贝的复杂度会指数级增加。例如，一个结构体包含指向另一个结构体的指针，而后者又包含指针成员，需要递归深拷贝。在嵌入式环境中，建议限制嵌套深度不超过 2 层，并优先使用固定大小数组。

4.4 结构体数组与指针算术

核心原理：结构体数组在内存中是连续存储的，数组名在表达式中会退化为指向首元素的指针。因此，Frame_t frames[4] 中，frames 的类型是 Frame_t *。指针算术 frames + i 等价于 &frames[i]，步长为 sizeof(Frame_t)。

操作流程：遍历结构体数组有三种等价方式：

下标法：for (i=0; i<4; i++) frames[i].id = i;
指针法：for (p=frames; p<frames+4; p++) p->id = i++;
偏移法：*(frames + i).id = i;（注意括号优先级）

表达式	类型	含义	典型用途
`frames`	`Frame_t *`	数组首地址	传参、遍历起点
`&frames[0]`	`Frame_t *`	首元素地址	与 frames 等价
`frames + 2`	`Frame_t *`	第三个元素地址	随机访问
`&frames[2]`	`Frame_t *`	同上	可读性更好

经验提醒：在嵌入式实时系统中，使用指针遍历结构体数组比下标法更高效（省去每次计算偏移量的乘法），但编译器通常会将下标法优化为指针算术。优先编写可读性强的下标法，除非在性能关键路径（如中断处理）中才手动优化为指针。

4.5 内存对齐与填充：从 sizeof 到硬件映射

核心原理：内存对齐是指编译器将变量的起始地址放置在其对齐边界上（通常是类型大小的整数倍）。结构体的对齐规则为：结构体总大小必须是其最大成员对齐值的整数倍。填充（Padding）是编译器在成员之间或结构体末尾插入的未使用字节，以满足对齐要求。

判断方法：计算结构体大小需遵循三步：

确定每个成员的对齐值（通常为 sizeof(成员类型)，但 uint8_t 为 1，uint32_t 为 4）。
按顺序放置成员，每个成员的偏移量必须是对齐值的整数倍，不足则填充。
结构体总大小必须是最大对齐值的整数倍，不足则在末尾填充。

实战场景：在嵌入式通信协议中，结构体常被直接映射到接收缓冲区。若未正确处理对齐，会导致解析错误。

// 错误示例：未考虑对齐
typedef struct {
    uint8_t  header;   // 偏移 0
    uint32_t length;   // 偏移 4（填充 3 字节）
    uint16_t crc;      // 偏移 8
} Packet_t;            // sizeof = 12，但实际数据仅 7 字节

// 正确做法：使用 #pragma pack(1) 或手动定义
#pragma pack(push, 1)
typedef struct {
    uint8_t  header;
    uint32_t length;
    uint16_t crc;
} PackedPacket_t;      // sizeof = 7，无填充
#pragma pack(pop)

风险说明：使用 #pragma pack(1) 虽然节省空间，但会导致非对齐访问。在 ARM Cortex-M 系列中，非对齐的 32 位访问会触发 HardFault 或降低性能。对于需要直接映射硬件寄存器的结构体，应使用 volatile 关键字，并确保结构体布局与寄存器地址完全一致。建议在结构体定义后添加 _Static_assert(sizeof(Packet_t) == 7, "Unexpected size"); 进行编译期校验。

4.6 综合案例：协议帧解析器的内存优化

背景与约束：某物联网网关需要解析来自传感器的 128 字节数据帧，帧格式为：1 字节帧头（0xAA）、2 字节长度、4 字节设备 ID、N 字节负载（最大 120 字节）、2 字节 CRC16。系统 RAM 仅 32KB，要求解析延迟小于 1ms。

初始现象与目标：初版代码使用 memcpy 将整个帧拷贝到结构体，再逐字段解析。实测发现：结构体因对齐产生 3 字节填充，且拷贝 128 字节耗时约 50μs，在 1kHz 中断频率下占用 5% CPU。目标是将解析时间降低至 20μs 以内，并减少内存占用。

分析判断过程：通过分析发现：

结构体定义未使用 #pragma pack，导致 sizeof(Frame_t) = 132 而非 129。
每次中断都执行 memcpy，而实际上可以直接在接收缓冲区上解析。
CRC 校验需要遍历整个帧，与解析可以合并。

实际操作步骤：

使用 #pragma pack(push, 1) 定义紧凑结构体，消除填充。
将接收缓冲区直接强转为 Frame_t *，避免拷贝。
在解析函数中同时计算 CRC，减少一次遍历。
使用 const 指针传递帧数据，确保只读访问。

#pragma pack(push, 1)
typedef struct {
    uint8_t  header;
    uint16_t length;
    uint32_t deviceId;
    uint8_t  payload[120];
    uint16_t crc;
} Frame_t;
#pragma pack(pop)

void ParseFrame(uint8_t *rxBuf, uint16_t rxLen) {
    Frame_t *pFrame = (Frame_t *)rxBuf;  // 零拷贝解析
    if (pFrame->header != 0xAA) return;
    uint16_t calcCrc = Crc16(rxBuf, rxLen - 2);
    if (calcCrc != pFrame->crc) return;
    // 直接访问 pFrame->payload
}

结果对比：优化后，解析时间从 50μs 降至 12μs（减少 76%），内存占用从 132 字节降至 129 字节，且消除了 memcpy 的堆栈开销。代价是代码可读性略有下降，且必须确保接收缓冲区是 1 字节对齐的（DMA 缓冲区通常满足）。

风险与代价：直接强转缓冲区为结构体指针，要求缓冲区地址满足结构体最大对齐要求（此处为 1，因为 pack(1)）。若未来修改为默认对齐，则必须使用 memcpy 或 memmove 避免非对齐访问。

复盘经验：在嵌入式开发中，结构体与指针的结合需要从内存布局、访问效率和硬件约束三个维度综合权衡。优先使用零拷贝解析，但必须通过编译期断言和运行时检查确保安全性。对于跨平台代码，避免依赖 #pragma pack 的编译器扩展，可手动定义字节序转换函数。