宏实现反射机制：结构体字段的宏定义，字段偏移量的计算，简单的序列化/反序列化
说到反射机制，很多C语言开发者第一反应是：“C语言哪来的反射？”
没错，C语言标准里确实没有反射。但我们在嵌入式开发中，经常需要知道结构体某个字段的偏移量，或者想把结构体数据打包成字节流发出去。这时候，宏就能帮我们“模拟”出反射的效果。
我个人习惯把这种技术叫做“穷人版反射”——虽然简陋，但在资源受限的MCU上，它比任何重量级框架都管用。
一、字段偏移量的计算：offsetof 宏
先看一个最基础的问题：怎么知道结构体里某个成员相对于起始地址的偏移？
标准库提供了 offsetof 宏，定义在 <stddef.h> 里。它的经典实现是这样的：
#define offsetof(type, member) ((size_t)&((type *)0)->member)这个写法很巧妙。它把地址0强制转换成结构体指针，然后取成员的地址。因为基地址是0，所以成员的地址值就是偏移量。
嗯，这里要注意：这个宏在C语言中是合法的，但在C++中有些编译器会警告。不过嵌入式开发大多用C，问题不大。
实际应用场景：
我在调试一个CAN总线协议栈时，需要把结构体字段映射到报文的不同字节位置。用 offsetof 可以精确算出每个字段在缓冲区中的位置，避免手动计算带来的错误。
二、用宏实现“字段注册”
真正的反射需要知道字段的名字、类型、偏移量、大小等信息。我们可以用宏来“注册”这些元数据。
// 定义一个“字段描述符”结构
typedef struct {
const char *name; // 字段名
size_t offset; // 偏移量
size_t size; // 字段大小
} field_desc_t;
// 宏：生成字段描述符
#define FIELD_DESC(type, member) \
{ #member, offsetof(type, member), sizeof(((type *)0)->member) }
// 使用示例
typedef struct {
uint8_t id;
uint32_t value;
uint16_t crc;
} sensor_data_t;
field_desc_t sensor_fields[] = {
FIELD_DESC(sensor_data_t, id),
FIELD_DESC(sensor_data_t, value),
FIELD_DESC(sensor_data_t, crc)
};你看，这样我们就有了一个“字段表”。遍历这个表，就能知道结构体的布局信息。
我的经验：
我曾经在一个项目里用这种方式实现了“自动化的Modbus寄存器映射”。结构体每个字段对应一个Modbus寄存器，通过字段表自动生成读写函数。省去了大量手写switch-case的重复劳动。
三、简单的序列化实现
有了字段表，序列化就变得很直接了。我们遍历字段表，把每个字段的数据按顺序拷贝到缓冲区里。
#define SERIALIZE_BUF_SIZE 256
int serialize(void *obj, field_desc_t *fields, int field_count, uint8_t *buf) {
uint8_t *ptr = buf;
for (int i = 0; i < field_count; i++) {
void *field_addr = (uint8_t *)obj + fields[i].offset;
memcpy(ptr, field_addr, fields[i].size);
ptr += fields[i].size;
}
return (int)(ptr - buf); // 返回序列化后的总字节数
}
// 反序列化
void deserialize(void *obj, field_desc_t *fields, int field_count, uint8_t *buf) {
uint8_t *ptr = buf;
for (int i = 0; i < field_count; i++) {
void *field_addr = (uint8_t *)obj + fields[i].offset;
memcpy(field_addr, ptr, fields[i].size);
ptr += fields[i].size;
}
}说白了，这就是把结构体当成一块连续内存来处理。但要注意：结构体可能有填充字节（padding），直接memcpy整个结构体可能会出问题。而按字段逐个拷贝，就能避开填充字节的干扰。
避坑指南：
我曾经在一个项目里直接对整个结构体做memcpy序列化，结果在PC上测试一切正常，下载到STM32上就乱码了。查了半天才发现是结构体对齐方式不同导致的。从那以后，我坚持用字段表逐个拷贝，再也没出过类似问题。
四、带类型信息的序列化
上面的例子只处理了基本的内存拷贝。如果字段类型不同（比如大小端问题），就需要更精细的控制。
我们可以扩展字段描述符，加入类型信息：
typedef enum {
FIELD_U8,
FIELD_U16,
FIELD_U32,
FIELD_FLOAT,
FIELD_STRING
} field_type_t;
typedef struct {
const char *name;
size_t offset;
field_type_t type;
size_t max_len; // 字符串时有效
} field_info_t;
#define FIELD_INFO(type, member, ftype) \
{ #member, offsetof(type, member), ftype, 0 }
#define FIELD_INFO_STR(type, member, maxlen) \
{ #member, offsetof(type, member), FIELD_STRING, maxlen }序列化时，根据类型做不同的处理：
int serialize_typed(void *obj, field_info_t *fields, int count, uint8_t *buf) {
uint8_t *ptr = buf;
for (int i = 0; i < count; i++) {
void *addr = (uint8_t *)obj + fields[i].offset;
switch (fields[i].type) {
case FIELD_U8:
*ptr++ = *(uint8_t *)addr;
break;
case FIELD_U16:
// 小端序写入
*ptr++ = *(uint16_t *)addr & 0xFF;
*ptr++ = (*(uint16_t *)addr >> 8) & 0xFF;
break;
case FIELD_U32:
// 小端序写入
for (int j = 0; j < 4; j++) {
*ptr++ = (*(uint32_t *)addr >> (j * 8)) & 0xFF;
}
break;
case FIELD_STRING:
strncpy((char *)ptr, (char *)addr, fields[i].max_len);
ptr += fields[i].max_len;
break;
default:
break;
}
}
return (int)(ptr - buf);
}为什么这样做？
你想想看，如果通信双方一个是小端MCU，一个是大端PC，直接拷贝整型数据就会出问题。按字节处理可以统一成网络字节序（大端），或者约定好一种字节序。我在做物联网网关时，就靠这套机制解决了不同平台间的数据交换问题。
五、知识体系总览
下面这张图总结了宏实现反射机制的核心逻辑：
六、实际项目中的注意事项
这套方法虽然好用，但有几个坑需要避开：
- 结构体对齐：不同编译器的默认对齐方式可能不同。如果序列化数据要在不同平台间交换，建议用
#pragma pack(1)强制1字节对齐，或者像我上面那样按字段逐个处理。 - 位域字段：位域（bit-field）的偏移量计算是未定义行为，
offsetof对位域无效。我的建议是：别在位域上玩这套，老老实实用普通字段。 - 指针字段：序列化指针本身没有意义，因为指针值在不同进程/不同时间点会变。需要序列化的是指针指向的数据，而不是指针本身。
- 版本兼容：结构体字段顺序变了怎么办？我习惯在序列化数据头部加一个版本号字段，反序列化时根据版本号选择对应的字段表。
一个小技巧：
如果你用GCC，可以用 __builtin_offsetof 代替自己写的 offsetof 宏。它更安全，而且能处理一些复杂情况（比如嵌套结构体）。不过为了可移植性，我一般还是用标准宏。
好了，关于宏实现反射机制的内容就聊到这里。这套方法虽然不如高级语言的反射那么强大，但在C语言的世界里，它已经能解决大部分“需要知道结构体布局”的问题了。从字段偏移量计算，到字段注册，再到序列化/反序列化，每一步都可以用宏来简化代码，提高可维护性。