直接 fwrite 结构体存在内存填充、平台对齐、字节序、非pod成员等多重风险,应逐字段序列化或改用 protocol buffers/json 等安全格式。

用 fwrite 直写结构体前,必须确认内存布局是否安全
二进制直写 struct 到 .dat 文件,本质是把内存里那一块字节原样拷过去。但 C++ 不保证结构体成员之间没填充(padding),也不保证不同编译器/平台的对齐方式一致。
比如这个结构体:
struct Person {
int id;
char name[20];
double salary;
};
在 x86-64 GCC 下,salary 前可能有 4 字节填充;换到 ARM 或 MSVC 编译,填充位置或大小可能变——直接 fwrite(&p, sizeof(p), 1, fp) 写出去,换机器读就大概率错乱。
- 检查实际占用:用
sizeof(Person)和offsetof手动算各字段偏移,确认和预期一致 - 强制紧凑布局:加
#pragma pack(1)或[[gnu::packed]](注意:会降低访问性能) - 更稳妥的做法:不依赖
sizeof(struct),而是逐字段fwrite,自己控制顺序和长度
用 fread 读回结构体时,不能跳过初始化和大小校验
直接 fread(&p, sizeof(p), 1, fp) 读,看似省事,但一旦文件损坏、版本升级、或写入时用了不同编译选项,p 的内容就不可信——尤其是含指针、std::string、std::vector 的结构体,二进制读会直接把垃圾地址塞进去,后续访问必崩。
- 读之前先
memset(&p, 0, sizeof(p)),清掉未初始化的填充字节 - 读完立刻校验返回值:
if (fread(&p, sizeof(p), 1, fp) != 1) { /* 文件提前结束或读错 */ } - 含 C 风格字符串的字段(如
char name[20]),读完要确保末尾是'\0',否则printf("%s", p.name)可能越界 - 绝对不要对含非 POD 成员的结构体这么做——
std::string的内部指针一读就失效
跨平台保存时,字节序(endianness)问题比想象中更隐蔽
Intel 和 AMD 是小端(little-endian),多数网络协议和嵌入式芯片用大端(big-endian)。如果结构体里有 int、float、double,直接二进制写,在另一端读出来就是错的数值——比如 0x12345678 在小端机存为 78 56 34 12,大端机按原顺序读就成了 0x78563412。
- 简单场景:统一转成网络字节序(大端)再写,用
htons/htonl/htobe64等函数 - 结构体字段多时,别手写每个字段转换,封装一个
serialize()成员函数,显式处理每个数值字段 - 文件头加 magic number 和 version 字段,比如前 4 字节写
0x44415401("DAT\1"),方便识别格式和字节序
真正需要长期保存时,二进制直写只是权宜之计
所谓「直写结构体」,只适合临时缓存、进程间快速传递、或同一程序同一编译环境下反复读写。只要涉及版本迭代(比如下次加个 bool is_active 字段)、跨语言(Python 要读这个 .dat)、或者用户手动编辑需求,它就会迅速失控。
- 字段增减会导致整个结构体偏移全乱,旧文件无法兼容新代码
- 没有字段名、类型信息,调试时只能靠猜——
0x3F800000是 float 1.0 还是 int 1065353216? - 不如用 Protocol Buffers 或 flatbuffers:定义 schema,自动生成序列化代码,天然支持向后兼容
- 哪怕只是简单需求,也建议用文本格式(如 JSON)+
nlohmann/json,可读、可调试、容错强
二进制直写最危险的地方不是它难,而是它太容易——几行代码就能跑通,然后埋下半年后才爆发的兼容性雷。
C++免费学习笔记(深入):立即使用
在学习笔记中,你将探索 C++ 的入门与实战技巧!











