根本原因是结构体对齐导致内存布局与二进制文件字节流不匹配；解决方法包括#pragma pack(1)、逐字段读写或使用序列化协议。
用 fread 读结构体时，为什么数据总错位？
根本原因不是文件损坏，而是结构体对齐（padding）和内存布局不匹配。C++ 编译器会在成员之间插入填充字节以满足地址对齐要求，而二进制文件里存的是“原始字节流”，没有对齐信息。
比如：
struct Data {
char a; // offset 0
int b; // offset 4（x86_64 下通常对齐到 4 字节）
char c; // offset 8
};该结构体 sizeof(Data) 很可能是 12，但实际有效数据只占 6 字节。若直接 fread(&obj, sizeof(Data), 1, fp)，就会把填充字节也读进来——或者更糟：写入时把填充字节当有效数据写进文件，导致跨平台或换编译器后解析失败。
- 解决办法：用
#pragma pack(1)或[[gnu::packed]]强制取消填充（注意：可能影响性能，且某些 CPU 对非对齐访问会 crash） - 更安全做法：逐字段读写，例如
fread(&obj.a, 1, 1, fp); fread(&obj.b, 4, 1, fp); fread(&obj.c, 1, 1, fp); - 永远检查
fread返回值是否等于预期项数，避免 EOF 或短读未察觉
std::vector<char></char> 和 char* 传给 fwrite 的区别在哪？
表面看都是“一串字节”，但生命周期和所有权语义完全不同。
立即学习“C++免费学习笔记（深入）”；
-
char buf[1024]; fwrite(buf, 1, 1024, fp);—— 安全，栈内存稳定 -
std::vector<char> v(1024); fwrite(v.data(), 1, v.size(), fp);</char>—— 合法，v.data()在 C++11 起保证返回连续内存，但要注意v不能在fwrite过程中被移动或销毁 -
char* p = new char[1024]; fwrite(p, 1, 1024, fp); delete[] p;—— 危险！若fwrite失败或抛异常，p可能泄露；应改用std::unique_ptr<char></char>管理
特别注意：std::vector<bool></bool> 是特化模板，底层不保证是连续 char 内存，绝不能传给 fwrite。
用 fseek 移动文件指针时，SEEK_CUR 和 SEEK_SET 混用为什么容易出错？
问题不在函数本身，而在你忘了 fseek 的偏移量单位是字节，而你脑子里想的是“第几个结构体”。比如结构体大小是 24 字节，你想跳到第 5 个，却写了：
fseek(fp, 5, SEEK_SET); // 错！这是跳到第 5 字节，不是第 5 个对象
正确写法必须显式乘上尺寸：
fseek(fp, 5L * sizeof(MyStruct), SEEK_SET);
-
SEEK_CUR常用于“先读一点，判断类型，再回退重读”，此时务必用fseek(fp, -n, SEEK_CUR)，而不是fseek(fp, pos - n, SEEK_SET)，因为后者依赖你记得住当前pos，而ftell在文本模式下不可靠 - Windows 下打开文件要用
"rb"模式，否则\r\n会被转成单个\n，导致fseek计算偏移错乱 -
fseek对于大于 2GB 的文件，在 32 位系统或旧 libc 上可能截断，建议用fseeko+off_t或 C++17 的std::filesystem::file_size配合std::ifstream::seekg
用 reinterpret_cast 把指针转成 char* 读二进制，有什么隐藏风险？
这种写法很常见：
MyStruct obj; fwrite(reinterpret_cast<char*>(&obj), sizeof(obj), 1, fp);
但它绕过了类型安全，且隐含三个关键假设：
- 目标类型
MyStruct是 trivially copyable（可用std::is_trivially_copyable_v<mystruct></mystruct>静态断言） - 没有虚函数、引用成员、非平凡构造/析构——否则
reinterpret_cast读出来的只是内存快照，无法还原对象语义 - 两端编译器对同一结构体的内存布局完全一致（包括字节序、对齐、bool/int 实现细节）
跨语言（如 Python/C++ 共享二进制协议）或跨平台（x86 vs ARM）时，这些假设大概率不成立。这时候应该用明确的序列化格式（如 Protocol Buffers），而不是裸指针 cast。
最常被忽略的一点：调试时用 gdb 查看 reinterpret_cast<char>(&obj)</char> 地址，看到的字节顺序取决于当前 CPU 的 endianness，而文件里存的字节顺序是你写入时的机器顺序——别默认它和你读的时候一样。
