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 匹配机制，自己掌控输入流节奏。虽然多写两行，但逻辑清晰、异常明确、调试友好。

JavaStoryDevelop

你接手一个需求时，是不是经常这样："改一个小字段 → 结果把不相关的代码也改了"、"需求说得很模糊 → 做着做着发现跑偏了"、"数据库加个字段 → 上线才发现漏了数据兼容"、"做了个新功能 → 一个月后自己都忘了当时怎么设计的"、"写到一半被中断 → 再回来不知道从哪继续"；这个 Skill 就是专门解决这些问题的。 它会自动探测你的项目环境（JDK、Spring Boot、ORM、数据库、前端框架），记在

下载

• 先用 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 自动分词更可靠

实际写的时候，最麻烦的不是语法，而是 Scanner 对“当前 token”的执念——它不认为自己该为你的业务逻辑兜底。留着一个没处理的 next() 调用，就足以让后面所有判断失效。