scanner.hasnextint()不能安全读取整数，因其仅校验token开头是否匹配整数模式、不消费输入、不处理换行符残留、不检测溢出与格式细节，且依赖locale和分隔符；真正安全需配合nextline()+正则+parseint。
Scanner.hasNextInt() 为什么不能直接用来“安全读取整数”
Scanner.hasNextInt() 只检查下一个 token 是否能被解析为 int，但它不消费输入流——也就是说，调用它之后，光标仍停在原位置。如果紧接着调用 scanner.nextInt()，确实能读到那个整数；但如果中间穿插了其他 nextXXX() 调用（比如 nextLine()），就容易因换行符残留导致跳过输入或阻塞。
常见错误现象：hasNextInt() 返回 true，但后续 nextInt() 却抛出 InputMismatchException——这通常是因为前一次读取（如 nextLine()）留下了未处理的换行符，而 nextInt() 不吃掉它，下一次 nextLine() 立刻返回空字符串，造成逻辑错乱。
- 它只对当前 token 生效，不保证整个输入行都是整数（比如
"123abc"会被认为是int，因为hasNextInt()只看开头是否匹配整数模式） - 它依赖
Scanner的分隔符，默认是空白字符，所以"123,456"中的"123,"不会被识别为 int - 它不处理溢出：
"2147483648"（超过Integer.MAX_VALUE）会返回false，但"-2147483649"同样返回false，无法区分是格式错还是范围错
正确搭配 hasNextInt() + nextInt() 的最小安全模式
要真正“验证后读取”，必须确保两次调用之间没有干扰操作，并清除可能的换行符残留。
典型安全写法：
Scanner scanner = new Scanner(System.in);
if (scanner.hasNextInt()) {
int value = scanner.nextInt(); // ✅ 消费 token
// 处理 value
} else {
scanner.next(); // ❗跳过非法 token，否则下次 hasNextInt() 还会卡在这儿
}
- 每次
hasNextInt()为false时，必须调用scanner.next()清除当前非法 token，否则循环会无限卡住 - 如果之后需要读取整行（比如用户先输数字、再输名字），在
nextInt()后加一句scanner.nextLine()吸收换行符，否则下个nextLine()会立刻返回空字符串 - 不要混用
nextInt()和nextLine()而不手动清理缓冲区——这是 90% 的新手卡点
想严格校验“一整行只能是整数”？别用 hasNextInt()
hasNextInt() 是基于 token 的，不是基于行的。如果你的需求是“用户必须单独输入一个整数，不能带空格、逗号、字母”，那它根本做不到。
此时应改用：
String line = scanner.nextLine().trim();
if (line.isEmpty()) {
// 处理空输入
} else if (line.matches("-?\d+")) { // 简单正则：可选负号 + 至少一位数字
try {
int value = Integer.parseInt(line);
// ✅ 安全拿到整数
} catch (NumberFormatException e) {
// 溢出等情况（如超长数字），parseInt 会抛异常
}
}
-
hasNextInt()对" 42 "返回true，但对"42 "（末尾空格）也返回true——它自动跳过前后空白，但你无法得知原始输入是否干净 - 正则
-?\d+不支持+开头、不支持科学计数法、不支持千分位，刚好符合“纯整数字符串”需求 - 用
Integer.parseInt()替代scanner.nextInt()可完全绕开 Scanner 内部状态问题，更适合行级校验
性能与兼容性注意点
hasNextInt() 底层会尝试用当前 locale 解析 token，如果 locale 设置为德语（小数点是逗号），它甚至可能把 "1.234" 当作整数（因为德语中 1.234 是千分位写法）。默认 locale 下一般没问题，但跨环境部署时容易出怪事。
- 如果程序需国际化，建议统一用
scanner.useLocale(Locale.ENGLISH)锁定解析行为 - 频繁调用
hasNextInt()+next()组合比直接nextLine()+ 正则慢约 15–20%，但对终端交互场景几乎无感 - Android 上部分旧版本
Scanner在输入流关闭后调用hasNextInt()可能抛IllegalStateException，务必包在 try-catch 里
hasNextInt() 帮你挡住了所有非数字输入，结果用户输了个 "123 "（带空格）你 happily 接收了，后面逻辑却因多出的空格崩了——这种边界情况，永远得靠你主动 trim 或正则兜底。
