Scanner.hasNextInt“判断不准”是因为它仅检查下一个分隔符界定的token是否可解析为int，不消耗输入，且受缓冲区残留字符、分隔符、进制及前序操作影响。
Scanner.hasNextInt 为什么有时“判断不准”
Scanner.hasNextInt 看起来是判断“接下来是不是整数”，但实际它依赖当前 Scanner 的分隔符（默认是空白字符）和输入缓冲区的**未消费内容**。如果输入流里有残留的换行符、空格或非法字符（比如 "123abc"），它可能返回 false，即使你肉眼觉得“后面明明有个数字”。更关键的是：它**不消耗输入**——只是预览，这点常被忽略。
常见错误现象：
用户输入 123↵ 后调用 hasNextInt() 返回 true，但紧接着调用 nextLine() 却读到空字符串——因为 nextInt() 没吃掉换行符，nextLine() 直接把它当成了行结束。
- 它只检查“从当前位置起，下一个由分隔符界定的 token 是否能解析为 int”，不是检查“整个输入流是否只含整数”
- 如果前一次读取（如
nextLine()）留下了换行符，而下一次想用hasNextInt()判断，它会卡在那个换行符上，直接返回false - 它对进制敏感：默认按十进制解析；若之前调用过
useRadix(16)，那"FF"也会返回true
正确搭配 hasNextInt + nextInt 的典型模式
最常用且安全的组合是：先用 hasNextInt() 预检，再用 nextInt() 消费。但必须确保输入流处于预期位置——也就是没有未处理的换行符干扰。
典型场景：用户连续输入多行，每行一个整数，中间可能夹杂空行或非数字行。
- 不要混用
nextLine()和nextInt()后不清理：例如用nextLine()读提示语后，立刻用hasNextInt()，大概率失败 - 推荐统一用
nextLine()读整行，再用Integer.parseInt()转换——这样你能完全控制字符串内容，也容易做日志或重试 - 如果坚持用
hasNextInt()，务必在每次调用前确认缓冲区干净：可加一句scanner.skip("\s*");跳过前置空白（但注意这会跳过所有空白，包括换行）
while (scanner.hasNextLine()) {
String line = scanner.nextLine().trim();
if (!line.isEmpty() && line.matches("-?\d+")) {
int n = Integer.parseInt(line);
// 处理 n
}
}hasNextInt 在 try-with-resources 或重定向输入下的行为差异
当 Scanner 包裹的是 System.in，hasNextInt() 会阻塞等待用户输入；但如果输入源是文件或字符串（如 new Scanner("abc 42")），它只在缓冲区内查找，不会等待。
这意味着：在自动化测试或 CI 环境中，用 hasNextInt() 判断“是否有下一个整数”是可靠的；但在交互式终端里，它可能让你的程序卡住，直到用户敲出一个整数或 EOF。
- 文件输入时：
hasNextInt()返回false表示已到末尾或下一个 token 不合法 - 标准输入时：
hasNextInt()可能永远阻塞——除非用户输入数字、Ctrl+D（Unix）或 Ctrl+Z（Windows）触发 EOF - 若需非阻塞检测，不能依赖
hasNextInt()，得改用System.in.available() > 0配合手动读字节（但复杂且不推荐）
替代方案：什么时候该放弃 hasNextInt
当你需要更强的容错、更清晰的错误反馈，或者输入格式不规整（比如数字混在句子中），hasNextInt() 就显得太“黑盒”。它不告诉你为什么失败，也不支持自定义校验逻辑。
- 要捕获具体错误（如溢出、空输入、带单位的数字如
"100MB"）：用nextLine()+ 正则 +Integer.valueOf()+try/catch - 要支持浮点数、十六进制、科学计数法等：
hasNextInt()无能为力，得用hasNextDouble()或自定义解析 - 要跳过注释行（如
"# max count: 5"）：必须先读整行，再用正则提取数字，hasNextInt()会把整行当一个 token 直接判否
真正容易被忽略的点是：很多人以为 hasNextInt() 是“输入合法性闸门”，其实它只是 Scanner 内部 token 切分机制的一次快照——它的行为高度依赖前序操作留下的缓冲区状态和当前分隔符设置。没理清这个，就容易陷入“明明输对了却一直 false”的循环。
