hasnextint()仅检测下一个token是否可解析为int且不消费输入，错误时需用next()清除非法token，否则缓冲区残留导致死循环；推荐统一用nextline()配合integer.parseint()并捕获numberformatexception。
hasNextInt() 不是万能的“安全开关”
它只检查输入流里**接下来的 token 是否能解析成 int**，不消费输入、不跳过错误内容。很多人以为调用 hasNextInt() 就万事大吉，结果下一次 nextInt() 还是抛 InputMismatchException——因为非法 token 还卡在缓冲区里没动。
- 典型错误现象：
hasNextInt()返回false后，紧接着调用next()或nextLine()却读到上一轮残留的字符串（比如用户输了个 "abc"，hasNextInt()返回false，但那个 "abc" 还在那） - 正确做法：只要
hasNextInt()为false，就得主动用next()把当前这个非整数 token “吃掉”，否则它永远挡在后面 - 别依赖
hasNextInt()做唯一校验——它对空格、换行、制表符都敏感；连续两个回车可能让它卡住，因为nextXXX()类方法默认以空白符分隔，但不会自动跳过空白块
遇到非数字输入时，Scanner 缓冲区会“卡住”
这是最常被忽略的底层行为：Scanner 的 token 匹配是“懒消费”的。匹配失败 ≠ 输入被丢弃。比如用户输入 123 abc 456，你调一次 nextInt() 得到 123，再调 hasNextInt() 返回 false（因为下一个 token 是 "abc"），但 "abc" 仍留在输入流里——下次再调 hasNextInt() 还是 false，形成死循环。
- 必须配合
next()清除当前非法 token，例如：if (!scanner.hasNextInt()) { scanner.next(); } - 如果后续还要读整行（比如混合读数字和描述），记得在清完非法 token 后补一个
nextLine()，否则换行符可能被遗留，影响下一次nextLine() - 不要用
scanner.nextLine()直接代替scanner.next()来清理——它会吞掉整个行，可能把后面合法的数字一并吃掉
替代方案：用 nextLine() + Integer.parseInt() 更可控
绕开 Scanner 的 token 匹配机制，自己掌控输入流节奏。虽然多写两行，但逻辑清晰、异常明确、调试友好。
- 先用
nextLine()拿整行字符串，再 trim() 去首尾空格，避免空行或纯空格导致NumberFormatException - 捕获
NumberFormatException，而不是靠hasNextInt()猜测——异常信息里直接告诉你哪段字符串转不了，方便日志或提示 - 性能无明显差异：对普通控制台输入，字符串解析开销远小于 I/O 阻塞本身；而且避免了 Scanner 内部状态混乱带来的隐性成本
- 示例片段：
String line = scanner.nextLine().trim(); if (line.isEmpty()) { System.out.println("输入为空，请重试"); continue; } try { int value = Integer.parseInt(line); // 处理合法数字 } catch (NumberFormatException e) { System.out.println("请输入有效整数，'" + line + "' 不符合格式"); }
Scanner 在循环中重复使用容易累积状态问题
很多人把 Scanner 当成“一次一用”的工具，但在 while 循环里反复调 hasNextInt() + nextInt()，又没处理失败分支，缓冲区里的脏数据越积越多，最终表现就是“程序卡住不动”或者“跳着读输入”。
立即学习“Java免费学习笔记（深入）”；
- 每次输入操作前，确保缓冲区干净：失败时用
next()或nextLine()显式清理，别指望下一轮自动重置 - 避免在同一个 Scanner 实例上混用
nextXXX()和nextLine()——前者不吞换行符，后者会立刻读走换行符，极易造成nextLine()返回空字符串 - 如果业务逻辑复杂（比如读多个不同类型字段），建议每轮输入都用
nextLine()统一入口，再按需解析，比靠 Scanner 自动分词更可靠
next() 调用，就足以让后面所有判断失效。 
