C++二进制文件操作中指针与数组的陷阱揭秘_技术教程

根本原因是结构体对齐导致内存布局与二进制文件字节流不匹配；解决方法包括#pragma pack(1)、逐字段读写或使用序列化协议。

根本原因不是文件损坏，而是结构体对齐（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 或短读未察觉

表面看都是“一串字节”，但生命周期和所有权语义完全不同。

char buf[1024]; fwrite(buf, 1, 1024, fp); —— 安全，栈内存稳定
std::vector v(1024); fwrite(v.data(), 1, v.size(), fp); —— 合法，v.data() 在 C++11 起保证返回连续内存，但要注意 v 不能在 fwrite 过程中被移动或销毁
char* p = new char[1024]; fwrite(p, 1, 1024, fp); delete[] p; —— 危险！若 fwrite 失败或抛异常，p 可能泄露；应改用 std::unique_ptr 管理

特别注意：std::vector 是特化模板，底层不保证是连续 char 内存，绝不能传给 fwrite。

问题不在函数本身，而在你忘了 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

这种写法很常见：

MyStruct obj;
fwrite(reinterpret_cast(&obj), sizeof(obj), 1, fp);

但它绕过了类型安全，且隐含三个关键假设：

跨语言（如 Python/C++ 共享二进制协议）或跨平台（x86 vs ARM）时，这些假设大概率不成立。这时候应该用明确的序列化格式（如 Protocol Buffers），而不是裸指针 cast。

最常被忽略的一点：调试时用 gdb 查看 reinterpret_cast(&obj) 地址，看到的字节顺序取决于当前 CPU 的 endianness，而文件里存的字节顺序是你写入时的机器顺序——别默认它和你读的时候一样。

C++二进制文件操作中指针与数组的陷阱揭秘