直接 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。
组合式C++代码评审方案，融合静态分析、AI推理、多轮迭代评审和C++专项检查，适用于PR审查、增量代码审查、全项目评审和代码质量评分，触发词包括review cpp、cpp代码评审、C++review、代码审查。
立即学习“C++免费学习笔记（深入）”；
- 简单场景：统一转成网络字节序（大端）再写，用
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，可读、可调试、容错强
二进制直写最危险的地方不是它难，而是它太容易——几行代码就能跑通，然后埋下半年后才爆发的兼容性雷。
