std::ios::binary仅禁用换行符转换（\r\n↔\n）和Ctrl+Z截断，确保读写字节原样传递；必须与in/out组合使用，否则无效。
用 std::ios::binary 打开文件时，到底改了什么
它不改变文件内容，只改变流对字节的解释方式。文本模式会做换行符转换（\r\n ↔ \n）和 Ctrl+Z 截断；二进制模式跳过所有这些处理，读多少字节就是多少字节。
常见错误现象：std::ifstream 读图片或 ZIP 文件时，中间突然截断、大小不对、解码失败——八成是忘了加 std::ios::binary。
- Windows 下尤其明显：文本模式遇到
\r\n会当成一个\n返回，写回去又变回\r\n，导致长度错乱 - Linux/macOS 表面“没区别”，但标准要求必须显式声明二进制，否则跨平台行为不可靠
-
std::ofstream同样要加，否则写入的\n可能被悄悄扩展成\r\n
std::ios::binary 必须和 std::ios::in/std::ios::out 一起用
单独写 std::ios::binary 没意义，它只是个修饰位，不能独立构成打开模式。
正确写法示例：
立即学习“C++免费学习笔记（深入）”；
std::ifstream fin("data.bin", std::ios::in | std::ios::binary);
std::ofstream fout("out.dat", std::ios::out | std::ios::binary);
std::fstream io("both.bin", std::ios::in | std::ios::out | std::ios::binary);
容易踩的坑：
- 写成
std::ios::binary | std::ios::out却没加std::ios::in—— 读操作会失败（fin.read()返回 0 字节） - 用
std::fstream时只传std::ios::binary，流默认以in|out打开，但某些旧编译器（如 VS2015 前）可能忽略binary位 - 路径含中文或特殊字符时，
std::ios::binary不影响编码处理——那是std::locale或宽字符接口的事
文本模式下 read() 和 getline() 的行为差异
文本模式下，std::istream::read() 仍按字节读，但 std::istream::getline() 和 operator>> 会受换行符转换影响；二进制模式下，所有读取都原样返回字节流。
典型问题场景：读取固定长度头部（比如 ELF 文件前 4 字节 magic number）
- 文本模式 +
read(buf, 4)：可能提前遇到\r\n被转义，实际只读到 3 字节就停住（尤其 Windows 上） - 二进制模式 +
read(buf, 4)：保证读满 4 字节，除非文件不足或出错 -
getline()在二进制模式下依然可用，但它仍以\n为分隔——不会识别\r\n，也不会跳过\r，所以读出来的字符串末尾可能带\r
性能与兼容性：不用 std::ios::binary 会慢吗
不会明显变慢，但会引入不确定性和隐式转换开销。现代 libc 实现中，文本模式的换行转换成本很低，真正的问题在语义层面。
关键点：
- 二进制模式禁用 EOF 检测优化：文本模式下某些实现遇到
Ctrl+Z（0x1A）直接设eofbit；二进制模式无视它 - POSIX 系统上，两种模式底层
open()系统调用参数无区别，差异全在 C++ streambuf 层 - 如果你用
fread()/fwrite()（C 风格），根本不存在“文本/二进制”开关——C 标准要求 fopen("rb") 显式声明，否则行为未定义
最常被忽略的一点：即使你只读纯 ASCII 文本，只要后续要精确控制字节位置（比如 mmap + offset 查找）、或者内容可能含 \0，就必须用二进制模式——文本模式下的 get() 遇到 \0 不会停止，但 >> 会把它当字符串结束。
