Scanner.hasNext() 不能可靠判断输入流结束，因为它会阻塞等待输入而非立即返回false；真实场景应依赖约定终止符（如“quit”）、空行或外部流关闭，而非依赖Ctrl+D/Z信号。
Scanner.hasNext() 为什么不能可靠判断控制台输入流是否结束
Scanner.hasNext() 在标准输入（System.in）上**不是“检测 EOF”的安全方式**。它在用户未输入任何内容时会阻塞等待，而不是立即返回 false；只有当底层流真正关闭（比如终端主动终止、重定向文件末尾、或 Ctrl+D/Ctrl+Z 被识别并消费后），它才可能返回 false。但这个过程受平台、终端缓冲、JVM 输入处理机制影响极大——你在 IDE 控制台敲回车，hasNext() 依然阻塞；你按 Ctrl+D，它也不一定立刻响应，有时要再敲一次回车才行。
真实场景下怎么预判“用户不会再输”
控制台输入没有“隐式结束”，必须靠约定或显式信号。常见做法是：
- 约定特殊输入作为终止标记，比如空行、单词
"quit"、或数字-1—— 这是最可控的方式 - 依赖
System.in被外部关闭（如echo "1 2 3" | java Main），此时hasNext()在流耗尽后返回false - 用
Scanner.hasNextLine()+scanner.nextLine().isEmpty()检查空行，比单纯hasNext()更贴近人机交互直觉
注意：hasNext() 默认使用空白符分隔，所以输入 "123\n456" 时，第一次 hasNext() 返回 true，调用 next() 得到 "123"，第二次 hasNext() 仍为 true（因为 "456" 还在缓冲区），并不会因换行就中断。
Ctrl+D / Ctrl+Z 到底怎么触发 hasNext() == false
这个行为高度依赖终端和 JVM：
- Linux/macOS 下：在空行时按
Ctrl+D，会向System.in发送 EOF；如果当前行已有内容（如刚输完"123"没回车），Ctrl+D会先提交该行，不会立即触发hasNext()为false - Windows 下：需在空行按
Ctrl+Z再回车，且某些 IDE（如 IntelliJ 的 Run Console）会吞掉该信号，导致hasNext()永远不返回false - 一旦触发成功，后续所有
hasNextXxx()都返回false，且再调用nextXxx()会抛NoSuchElementException
别指望它做实时“流存活检测”——它只反映“上次读取后，缓冲区是否还有符合分隔符的 token”，不是“操作系统级流状态”。
更健壮的替代方案：用 hasNextLine() + 显式退出逻辑
如果你要写一个持续读取直到用户放弃的交互程序，直接用 hasNext() 容易卡死或误判。推荐模式：
Scanner sc = new Scanner(System.in);
while (true) {
System.out.print("输入数字（输入 'done' 结束）: ");
if (!sc.hasNextLine()) break; // 流关闭时跳出
String line = sc.nextLine().trim();
if (line.equalsIgnoreCase("done")) break;
try {
int n = Integer.parseInt(line);
System.out.println("收到: " + n);
} catch (NumberFormatException e) {
System.out.println("请输入有效数字");
}
}
这样既避免阻塞陷阱，又把控制权交给用户语义（比如 “done”），还兼容 IDE 和各种终端。记住：hasNext() 是为“批量解析已知格式输入”设计的，不是为交互式会话做“流探活”准备的。
真正容易被忽略的是：哪怕你用了 hasNextLine()，如果用户没按回车，nextLine() 依然会阻塞——控制台输入永远需要回车确认，这是终端行为，Scanner 无法绕过。
