scanner.hasnext() 不返回 false 而是阻塞等待输入，因其设计为阻塞式读取：当输入缓冲区为空且 system.in 未关闭或未收到 eof 时，会持续等待有效 token，非 bug。
Scanner.hasNext() 为什么有时不返回 false 而是一直卡住
因为 hasNext() 默认等待用户输入，直到有有效 token 或流被显式关闭。它不因“没输东西”就返回 false，而是阻塞在输入缓冲区为空时——这不是 bug，是设计行为。
- 标准输入（
System.in）是交互式流，没有 EOF 信号，hasNext()就一直等 - 管道或重定向输入（如
java Main ）中，文件末尾会触发 <code>hasNext()返回false - 在 IDE（如 IntelliJ）的 Run Console 中，无法用 Ctrl+D / Ctrl+Z 模拟 EOF，容易误以为“卡死”
用 hasNextLine() + nextLine() 替代 hasNext() 做行级非阻塞判断
hasNextLine() 同样会阻塞，但它和 nextLine() 配合更可控：只要用户按了回车，哪怕只输了个换行，hasNextLine() 就返回 true，不会卡在“等第一个字符”上。
- 适合读取多行文本、命令行交互菜单、逐行解析场景
- 比
hasNext()更贴近真实输入节奏：回车即视为一次输入完成 - 注意：
nextLine()会消费换行符，若混用nextInt()等方法后没调用nextLine()清缓存，会导致下一次hasNextLine()立即返回true（读到残留换行）
示例：
Scanner sc = new Scanner(System.in);
while (sc.hasNextLine()) {
String line = sc.nextLine();
if (line.isEmpty()) break; // 空行退出
System.out.println("Got: " + line);
}
真正非阻塞？别用 Scanner，改用 BufferedReader + ready()
Scanner 本质不支持非阻塞 I/O。ready() 是少数能快速探测输入是否可读的方法，但仅适用于已知连接稳定、且底层流支持 available() 的情况（如文件、管道），对终端控制台效果有限。
-
BufferedReader.ready()返回true表示至少有一个字符可读（不阻塞），但不能保证整行；返回false不代表没数据，可能只是还没来得及缓冲 - Windows 下
System.in的ready()几乎总返回false，除非已敲回车 - 跨平台健壮做法：放弃“自动非阻塞”，改用超时线程 +
System.in.available()探测（需额外处理字节流）
简单替代写法（无超时，但避免 Scanner 的 token 缓存陷阱）：
BufferedReader br = new BufferedReader(new InputStreamReader(System.in));
String line;
while ((line = br.readLine()) != null) {
if (line.trim().isEmpty()) break;
System.out.println("Read: " + line);
}
Scanner 关闭后调用 hasNext() 抛 NoSuchElementException
一旦调用 sc.close()，关联的 System.in 会被关闭，后续任何 hasNext()、next() 都抛 NoSuchElementException，且无法恢复。
- 不要在循环中反复 new Scanner 并 close ——
System.in关一次就废了 - 如果必须多次读取，复用同一个
Scanner实例，全程不 close - 单元测试里用
new Scanner("abc\n123")模拟输入，避免碰真实System.in - JVM 退出时
System.in自动释放，不 close 也不会泄漏
nextInt() 和 nextLine() 导致的“跳过输入”，以及在终端里傻等 hasNext() 返回 false。记住：它不是“有没有输入”，而是“有没有下一个 token”——而 token 的边界由分隔符决定，默认空格/换行都算分隔，但没内容时它就干等着。Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
