必须用 std::ios::binary 打开二进制文件，否则 Windows 遇 \x1A 误判 EOF；read() 需传 char* 和正确 streamsize，不自动空终止，不可用 string::data()。
用 std::ifstream 以二进制模式打开文件是前提
不加 std::ios::binary 标志，Windows 下读取 \x1A（即 ASCII 26）会触发意外 EOF，Linux 虽不报错但行为不一致。必须显式指定，否则 read() 可能提前结束或读出错误字节数。
- 正确写法：
std::ifstream file("data.bin", std::ios::binary); - 错误写法：
std::ifstream file("data.bin");（文本模式，默认换行转换） - 如果后续还要写入，可叠加：
std::ios::in | std::ios::binary，但std::ifstream默认就是只读，无需显式写in
read() 的参数和长度陷阱
read() 不自动空终止，也不检查缓冲区边界，传错长度会导致越界或漏读。它只负责把字节搬进内存，其余全靠你兜底。
- 第一个参数是
char*或unsigned char*，不能传std::string::data()（C++11 后虽可写，但std::string不保证连续且无 null 截断风险） - 第二个参数是
std::streamsize，不是size_t—— 虽常等价，但跨平台时别强转；直接用sizeof(buf)或vec.size()更安全 - 常见错误：
file.read(buf, sizeof(buf)-1)—— 多此一举，二进制不需要留 '\0' 位
char buf[1024]; file.read(buf, sizeof(buf)); // 正确：全读 std::cout << file.gcount() << " bytes read\n"; // 必须检查实际读了多少
读完必须检查 gcount() 和状态位
read() 即使失败也几乎不抛异常（默认关闭异常位），仅置标志位。不查 gcount() 就以为读满了，是生产环境最常踩的坑。
-
file.gcount()返回最后一次read()实际读取的字节数，可能小于请求值（如到 EOF、磁盘错误） -
file.fail()或file.eof()要分开看：eof()表示“刚读到末尾”，fail()表示格式或底层失败（如权限不足） - 别依赖
!file判断——它等价于(fail() || bad())，但掩盖了到底是没读完还是根本打不开
file.read(buf, sizeof(buf));
if (file.gcount() == 0 && file.eof()) {
// 真·空文件或已读完
} else if (file.gcount() < sizeof(buf) && file.eof()) {
// 正常读到尾，最后一块不满
}
大文件或未知大小时，别硬分配栈缓冲区
栈上开几 MB 缓冲区（比如 char buf[4*1024*1024]）在某些嵌入式或限制栈空间的环境会直接崩溃。堆分配更稳妥，且现代 std::vector 配合 data() 完全兼容 read()。
立即学习“C++免费学习笔记（深入）”；
- 推荐方式：
std::vector<char> buf(8192); file.read(buf.data(), buf.size());</char> - 想一次读完？先
file.seekg(0, std::ios::end); auto size = file.tellg(); file.seekg(0);，再resize—— 但注意tellg()对某些流（如管道）返回 -1 - 性能提示：单次
read()过大（>64KB）未必更快，内核有缓冲策略，通常 4–64KB 是较优区间
read() 那一行，而是判断“我到底读到了什么”——尤其是跨平台、跨编译器、跨文件系统时，gcount() 和 eof()/fail() 的组合含义容易被想当然。 
