直接用 fwrite 写结构体导致读取错乱，是因为编译器对齐填充的 padding 字节也被写入；正确做法是手动序列化各字段或谨慎使用 #pragma pack(1)，但需注意跨平台兼容性与非 POD 类型（如 std::string）不可直写。
直接用 fwrite 写结构体，为什么读出来字段全乱了？
因为结构体在内存中默认按编译器对齐规则填充，fwrite 只是把那一片连续内存原样倒进文件——但对齐字节（padding）也被写进去了。你没意识到的“空洞”，成了读取时的错位根源。
- 常见错误现象：
int字段读出来是0x00001234变成0x12340000，或字符串首地址变成非法指针 - 根本原因：结构体成员间存在未声明的 padding 字节，
fwrite(&s, sizeof(s), 1, fp)把 padding 也写了进去；而读取端若没做相同对齐，就直接按字段偏移解包，必然错位 - 使用场景：跨平台存档、进程间共享二进制数据、性能敏感的日志序列化（不追求可读性）
- 实操建议：要么显式禁用对齐（慎用），要么手动序列化每个字段（推荐）
#pragma pack(1) 能一劳永逸解决对齐问题吗？
能压平 padding，但只在当前编译单元生效，且极易引发隐性崩溃。
- 参数差异：
#pragma pack(1)强制 1 字节对齐；#pragma pack(4)是多数 x86 默认值；省略参数则恢复默认对齐 - 容易踩的坑：
#pragma pack影响所有后续结构体，若头文件里没配对#pragma pack()，会导致下游代码结构体布局突变，出现难以复现的segmentation fault - 兼容性影响：ARM64 等架构对非对齐访问可能直接触发
bus error，即使 x86 允许，性能也会下降（CPU 需多周期处理） - 实操建议：仅在定义纯数据结构（不含虚函数、引用、std::string 等）且明确控制整个编译单元时使用；写完立刻
#pragma pack()恢复
用 memcpy 手动拷贝字段，比 fwrite 效率低吗？
几乎没差别。现代编译器对固定长度的 memcpy 会内联为单条指令，和直接 fwrite 原生结构体耗时基本一致。
- 为什么这样做：绕过 padding，只写你真正关心的字段，字段顺序和类型完全可控
- 示例：
struct Data { int a; char b; double c; }; Data s = {42, 'x', 3.14}; fwrite(&s.a, sizeof(s.a), 1, fp); fwrite(&s.b, sizeof(s.b), 1, fp); fwrite(&s.c, sizeof(s.c), 1, fp); - 关键点：必须严格保持写入/读取顺序一致；浮点数注意平台字节序（x86 和 ARM 通常都是小端，但嵌入式设备未必）
- 性能提示：如果结构体很大、字段很多，可先
memcpy到临时 buffer 再fwrite一次，减少系统调用开销
结构体里有 std::string 或指针，还能直接二进制写入吗？
不能。它们不是 POD 类型，内存布局不固定，fwrite 只会写出栈上对象本身（比如 std::string 的内部指针），而不是它指向的堆内存内容。
- 常见错误现象：读取后
std::string析构时报double free，或字符串内容显示为乱码/空 - 根本原因：
std::string通常包含指向堆内存的char*成员，该指针值写入文件毫无意义；同理，任何裸指针、std::vector、虚函数表指针都不能直写 - 实操建议：拆解为「长度 + 数据」两段写入，例如先写
s.length()，再写s.data()；读取时先读长度，再分配 buffer 读数据，最后构造新对象 - 额外提醒：涉及
std::string时，必须考虑编码（如 UTF-8），二进制写入不自动处理编码转换
对齐和序列化不是“设个 pragma 就完事”的事。真正麻烦的是混合了 POD 字段和 STL 容器的结构体——这时候字段级手动序列化不是过度设计，而是唯一靠谱的路径。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
