Windows下不加ios::binary读写二进制数据必出错：换行符被转为\r\n、\x1A被误判为EOF、结构体读写错位；Linux虽无换行转换，但文本模式仍可能因\0截断；跨平台必须显式使用ios::binary。
Windows 下不加 ios::binary 读写二进制数据，大概率会出错：换行符被悄悄转换、遇到 \x1A 被当成 EOF 截断、结构体读写错位。Linux 下虽无换行转换问题，但用文本模式读含 \0 的二进制数据仍可能被 std::string 误截断。
Windows 下 \n 会被自动转成 \r\n，且 \x1A 触发提前 EOF
这是最常踩的坑。C++ 标准库在 Windows 文本模式下会对换行符做平台适配：写 "abc\n" 实际落盘是 "abc\r\n"；读时又把 \r\n 合并成单个 \n。更危险的是，一旦二进制数据里恰好有字节 \x1A（DOS 时代的 EOF 标记），ifstream::read() 或 fgets() 会直接停住，后续字节全丢。
- 错误示例：
ofstream f("data.bin"); f.write(buf, len);—— 在 Windows 上，若buf含\n，落盘变\r\n；若含\x1A，写入可能被截断 - 正确做法：所有二进制 I/O 必须显式加
ios::binary，例如ofstream f("data.bin", ios::binary); - 注意：
fopen("file", "w")和fopen("file", "wb")行为不同，后者才真正绕过转换
std::string 不适合存原始二进制数据
因为 std::string 构造和访问默认以 <p>因为 <code>std::string 构造和访问默认以 \0 为终止，而二进制数据天然可能含多个 \0 字节。用它中转会导致长度丢失或内容截断。
<p>因为 <code>std::string 构造和访问默认以 \0 为终止，而二进制数据天然可能含多个 \0 字节。用它中转会导致长度丢失或内容截断。 字节。用它中转会导致长度丢失或内容截断。
- 错误写法：
std::string s(buf, len); f.write(s.c_str(), s.size());—— 若buf开头就有\0，s长度变成 0 - 安全替代：
std::vector<char> data(buf, buf + len); f.write(data.data(), data.size());</char> - 若坚持用
std::string，得用带长度的构造：std::string s(buf, len);，且传给write()时必须显式传s.size()，不能依赖c_str()
Linux 下文本/二进制模式行为一致，但习惯仍要加 ios::binary
Linux 系统本身不转换换行符，所以 fopen("f", "w") 和 fopen("f", "wb") 写 \n 结果一样。但这只是巧合，不是规范保证。
立即学习“C++免费学习笔记（深入）”；
- 跨平台代码不能依赖这个“一致性”——今天跑 Linux 没问题，明天上线 Windows 就崩
-
ios::binary是明确语义：我不需要任何隐式转换，请原样搬运字节 - 即使只在 Linux 开发，也建议统一加
ios::binary，避免团队新人误删后引发隐蔽 bug
真正麻烦的不是换行符转换，而是结构体二进制序列化时的字节对齐、大小端、成员 padding —— 这些和打开模式无关，但常被误认为是“模式没设对”。ios::binary 只解决传输层保真，不解决内存布局兼容性。
