必须使用ios::binary标志，否则Windows下会错误转换换行符（\n↔\r\n）并遇\x1A截断，导致图片、音频等二进制数据损坏；应显式指定该标志，避免文本模式干扰。
二进制文件读写必须用 ios::binary 标志
不加这个标志，ifstream 或 ofstream 会默认按文本模式处理：Windows 下自动把 \n 转成 \r\n，读取时又反向转换；遇到 \x1A（EOF 字符）直接截断。这对图片、音频、序列化对象等二进制数据是灾难性的。
实操建议：
- 所有二进制 I/O 必须显式指定
ios::binary，例如：ofstream fout("data.bin", ios::binary); - 文本文件可以省略该标志，但加上也无害；混用会导致不可预测的换行/截断问题
-
fread/fwrite（C 风格）默认就是二进制，无需额外设置，但需注意平台字节序和结构体对齐
std::string 和 std::vector 适合做二进制缓冲区
文本文件常用 std::string 存行或小段内容，但二进制数据可能含 \0 字节，std::string 的 c_str() 或构造函数会误判为结尾。更安全的是用 std::vector 或 std::basic_string（保留空字符）。
常见错误现象：
立即学习“C++免费学习笔记（深入）”；
- 用
std::string s(buf, len)构造二进制数据，但buf中有\0→ 实际只拷贝到第一个\0 - 用
s.data()传给write()却没传长度 → 写入长度被\0截断
正确做法：
std::vectorbuf(1024); fin.read(buf.data(), buf.size()); // 显式传长度 // 或 std::string bin_data; bin_data.assign(buf.begin(), buf.end()); // 不依赖 \0 终止
文本文件适合人读，二进制文件适合机器高效存取
文本文件（如 JSON、CSV、XML）可直接用编辑器查看、grep 搜索、Git diff 对比，但解析慢、体积大；二进制文件（如 Protocol Buffers、自定义结构体 write(reinterpret_cast）体积小、读写快，但无法直读、不可 diff、跨平台需处理字节序和对齐。
使用场景判断：
- 日志、配置、用户可见数据 → 文本优先
- 游戏资源包、传感器原始采样、网络协议载荷、高频序列化 → 二进制优先
- 需要长期存档或跨语言互通 → 选带 schema 的二进制格式（如 FlatBuffers），别手写
memcpy
结构体写入二进制文件前必须考虑内存对齐与字节序
直接 write() 一个结构体，看似简单，实际埋雷：编译器插入填充字节（padding），不同平台结构体布局可能不同；多字节整数在 x86 是小端，ARM 可能是大端。
容易踩的坑：
- 结构体含
bool、char、int混排 → 实际大小 ≠ 成员字节和，sizeof(S)不等于你算出来的值 - 用
#pragma pack(1)强制紧凑对齐 → 解决 padding，但可能降低访问性能，且需两端一致 - 跨平台传输整数 → 必须用
htons()/htonl()或手动翻转字节，不能直接写int32_t
示例（安全写入紧凑结构）：
struct __attribute__((packed)) Header {
uint32_t magic; // 网络序写入
uint16_t version;
};
Header h = {htons(0x1234), htons(1)};
fout.write(reinterpret_cast(&h), sizeof(h));
二进制文件的“高效”是以牺牲可读性、可移植性和调试便利性换来的，真正上线前务必验证字节序、对齐、边界条件——尤其是从文件读回结构体后，检查每个字段是否符合预期。 
