直接调用 std::ifstream::eof() 判断文件末尾几乎总是错误的，因为它仅在上一次读取失败且原因为到达文件末尾时才返回 true；正确做法是调用 read() 后检查 gcount() 值来判断实际读取字节数。
用 std::ifstream::eof() 判断文件末尾？别信它
直接调用 eof() 检查是否到文件末尾，几乎总是错的。它只在**上一次读取操作失败后且失败原因是到达文件末尾时**才返回 true。也就是说，eof() 是“事后诸葛亮”，不是“事前预警”。常见错误是写成：
while (!file.eof()) { file.read(...); }——这会导致最后一次读取失败后仍尝试处理脏数据，甚至多循环一次。
read() 和 gcount() 配合才是可靠方案
对二进制文件，应始终依赖 read() 的实际行为：它不保证读满请求字节数，可能因文件尾、I/O 错误或缓冲限制提前返回。关键在于检查 gcount() 返回值，它给出上一次 read() 真正读入的字节数。
-
gcount() == 0：未读取任何字节（已到文件末尾，或发生不可恢复错误） gcount() ：读取不完整，大概率是文件末尾-
gcount() == requested_size：读取完整，可继续
示例（安全读取固定大小块）：
std::ifstream file("data.bin", std::ios::binary);
char buf[1024];
while (file.read(buf, sizeof(buf))) {
// 成功读满 1024 字节
process(buf, sizeof(buf));
}
if (file.gcount() > 0) {
// 最后一次 read() 未读满，但仍有数据（即文件末尾）
process(buf, static_cast<size_t>(file.gcount()));
}
为什么不用 peek() 或 good() 做预判
peek() 对二进制流不可靠：它可能触发底层缓冲填充，导致后续 read() 行为异常；某些实现中，对空文件调用 peek() 后再 read() 可能跳过首字节。good() 是综合状态检查，无法区分“未到末尾”和“只是上次读取失败（比如权限问题）”。真正有效的判断必须绑定在具体读取动作之后，而不是靠状态函数猜。
大文件 + 内存映射场景下 EOF 更隐蔽
如果用 mmap() 或 CreateFileMapping 映射整个文件，EOF 概念就消失了——你拿到的是一个内存区域，长度由 stat() 或 GetFileSize() 决定。此时所谓“读取完毕”完全取决于你遍历的偏移量是否超过 st_size。容易忽略的是：映射长度可能小于文件大小（如未指定 MAP_PRIVATE 或映射参数错误），导致越界访问静默失败或 SIGBUS。务必校验 mmap() 返回地址和 st_size，不要依赖流式接口的 EOF 语义。
立即学习“C++免费学习笔记（深入）”；
