应使用 while (cin >> x) 而非 while (!cin.eof())，因 eof() 仅在读取失败后置位，导致末次有效数据被重复处理；而 cin >> x 以读取结果为条件，成功才进入循环，天然避免重复且可及时响应失败。
用 while (cin >> x) 代替 while (!cin.eof())
直接结论：只要你在循环条件里写 while (!cin.eof())，就大概率会重复输出最后一条记录。这不是 bug，是流状态更新时机导致的逻辑错位。
eof() 只在**尝试读取失败后**才被置为 true，而此时上一次成功的读取结果还留在变量里。下一轮循环仍会用这个旧值再处理一次。
- 正确做法是把读取操作本身作为循环条件：
while (cin >> x)—— 成功读入才进入循环体 -
cin >> x返回的是cin对象（支持隐式转为 bool），失败时自动转为 false - 该方式天然跳过无效输入（如非数字字符），且不会多跑一次循环
遇到空行或非法输入时，cin >> x 会卡住吗？
不会卡住，但流会进入 failbit 状态，后续所有读取都直接失败，直到你手动恢复。
- 如果输入是
"123\nabc\n456"，cin >> x读到abc时失败，x保持原值（比如仍是 123），流状态变为 false - 下一轮循环直接跳出，不会重复输出 123 —— 这正是你要的效果
- 若需继续读后面的有效数据（如 456），得调用
cin.clear()清除错误标志，并用cin.ignore()跳过坏字符
从文件读取时，结尾换行符会影响 eof() 吗？
不影响 eof() 的触发时机，但会影响你对“最后一行是否被读完”的判断。
立即学习“C++免费学习笔记（深入）”；
- 文件末尾有无换行符，
cin >> x行为一致：只要能解析出有效值，就读入并返回 true - 但如果你用
getline(cin, s)，末尾换行符缺失可能导致最后一行不被识别为完整行（getline在遇到 EOF 且未读到 \n 时仍会成功提取已有内容） - 所以对数字读取，别依赖文件格式细节；对行读取，优先检查
getline返回值而非eof()
为什么 cin.peek() == EOF 也不能当循环条件？
因为 peek() 只看下一个字符，不推进读取位置，且无法区分“刚到文件尾”和“下一个是非法字符但还没读”的情况。
- 例如输入
"123x"，cin.peek()返回'x'，不是EOF，但cin >> x下次就会失败 - 它不能替代读取动作本身的状态反馈，属于“猜”，不可靠
- 唯一安全的依据，永远是读取操作的返回值
真正容易被忽略的点是：流状态不是“描述当前是否在 EOF”，而是“描述上一次 I/O 操作是否成功”。所有基于状态查询的循环条件，本质上都在用过去的结果预测未来——只有把读取动作放进条件里，才能让判断和动作原子化。
