feof()不能用于提前判断文件末尾，而应在读操作失败后用以区分EOF与其他错误；正确做法是先读再检查返回值，如while((c=fgetc(fp))!=EOF)。
用 feof() 判断文件末尾？别这么干
直接说结论：feof() 不是“检测是否到了 EOF”，而是“上一次读操作是否因遇到 EOF 而失败”。它永远滞后一步，**不能用来提前判断下一次读会不会失败**。几乎所有新手误用都栽在这点上。
典型错误现象：fgetc() 返回 EOF 后，再调一次 feof() 才返回真——但此时你已经读过头了，还可能把 EOF 当作有效字符处理。
正确思路：先读，再检查返回值；而不是先查 feof()，再决定读不读。
- 对
fgetc()、fread()、fgets()等函数，必须检查其返回值是否异常（如EOF、nullptr、0） -
feof()只应在读操作失败后，用于区分失败原因是“文件结束”还是“其他错误（如磁盘故障）” - C++ 流（
std::ifstream）更推荐用fail()/eof()成员函数，但逻辑同样适用：先尝试读，再查状态
fgetc() 循环里怎么安全读到末尾
最常见场景：逐字节读取文本文件。错误写法是 while (!feof(fp)) { c = fgetc(fp); ... }——这会导致最后一个字符被重复处理一次。
立即学习“C++免费学习笔记（深入）”；
原因：当 fgetc() 读到最后一字节后，文件指针还没到 EOF；下次调用时才返回 EOF，但循环体已执行完上一轮，此时 !feof() 还为真，于是进入下一轮，c 被赋值为 EOF，却没做校验就参与后续逻辑。
正确写法只有一种核心模式：把读操作放在循环条件里。
int c;
while ((c = fgetc(fp)) != EOF) {
// 正常处理 c
}- 注意括号：
(c = fgetc(fp)) != EOF，赋值必须加括号，否则优先级出错 -
c必须是int类型，不能是char——因为EOF是负整数（通常 -1），而char可能是无符号的，导致永远不等于EOF - 如果需要区分“读失败”和“读到 EOF”，可在循环外用
ferror(fp)检查是否出错
std::ifstream 的 eof() 和 fail() 怎么配合用
C++ 流对象的 eof() 成员函数行为和 C 的 feof() 一致：只有在某次提取操作失败且原因为 EOF 时才返回 true。它不是预测器。
典型错误：用 while (!ifs.eof()) { ifs >> x; ... } ——和 C 版本一样，x 可能未成功读入，却继续处理旧值。
更可靠的方式是依赖流的隐式布尔转换（即检查读操作是否成功）：
int x;
while (ifs >> x) {
// x 已成功读入，可安全使用
}-
operator>>返回引用自身，流在失败时转为 false，成功时为 true - 该方式自动覆盖
failbit、eofbit、badbit三种失败情形 - 若需单独判断是否因 EOF 结束，可在循环结束后调用
ifs.eof()，但仅用于诊断，不用于控制流程 - 用
getline()时同理：while (getline(ifs, line)) { ... }
二进制读取（fread()）时 feof() 完全没用
fread() 的返回值是实际读取的元素个数，它不返回 EOF，也不设置流的 eofbit 直到真正越界。这意味着：feof() 在二进制读中几乎无法提供有用信息。
常见错误：用 fread() 读结构体或数组后，靠 feof() 判断是否读完——结果是最后一次读可能只读了部分数据，但 feof() 还是 false，程序误以为还有更多。
正确做法永远基于 fread() 的返回值判断：
size_t n = fread(buf, sizeof(int), 100, fp);
if (n == 0) {
// 一个元素都没读到：可能是 EOF，也可能是 error
if (ferror(fp)) { /* 处理错误 */ }
else if (feof(fp)) { /* 真正到末尾 */ }
} else {
// 成功读了 n 个元素，处理它们
}-
fread()成功时返回请求数量；少于请求数量时，必须结合ferror()和feof()区分原因 - 不要假设“读不满就是 EOF”——磁盘满、权限不足等也会导致读不满
- 对大文件，
fread()可能因系统缓冲策略分多次返回，不能靠单次调用结果推断文件长度
真正容易被忽略的是：所有这些函数的状态标志（feof()、ferror()、流的 eofbit 等）都是“sticky”的——一旦置位，会一直保持，直到你显式清除（如 clearerr() 或流的 clear()）。所以每次检查前，得确认你面对的是本次读操作引发的状态，而不是上次遗留的。
