如何利用 Scanner.hasNextInt() 在读取前验证输入的数据类型

为什么 Scanner.hasNextInt() 不能直接拿来“安全读取整数”

hasNextInt() 只做一件事：看一下下一个 token 能不能解析成 int。但它看完就走，不消费输入流——光标还停在原地。这本身没什么问题，但一旦你后续调用 nextInt()，它会去取那个 token，中间如果混了别的 nextXXX()（比如 nextLine()），换行符残留就会跳出来捣乱。

最常见的一个翻车场景：hasNextInt() 明明返回了 true，但接下来的 nextInt() 却抛出 InputMismatchException。追根溯源，往往是因为前一次 nextLine() 留下的换行符没被吃掉，nextInt() 又不负责擦屁股，于是下一次 nextLine() 直接返回空字符串，逻辑全乱套。

• 它只看当前 token 的开头是否匹配整数格式，而不是整行。比如 "123abc" 会被当作整数，因为 hasNextInt() 只检查 token 开头有没有数字。
• 它依赖 Scanner 的默认分隔符（空白字符），所以输入 "123,456" 时，"123," 不会被识别为 int——因为逗号不是分隔符，而是 token 的一部分。
• 它不处理数值溢出：像 "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()

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 内部状态管理，更适合行级校验。

性能与兼容性：一些容易被忽视的细节

• 如果程序需要国际化，建议统一加上 scanner.useLocale(Locale.ENGLISH) 锁定解析行为。
• 频繁调用 hasNextInt() + next() 组合比直接 nextLine() + 正则慢约 15–20%，但对终端交互场景几乎无感，不用太在意。
• Android 上部分旧版本 Scanner 在输入流关闭后调用 hasNextInt() 可能抛 IllegalStateException，最好包在 try-catch 里。

实际用的时候，最容易被忽略的是：你以为 hasNextInt() 帮你挡住了所有非数字输入，结果用户输了个 "123 "（带空格）你 happily 接收了，后面逻辑却因为多出的空格崩了——这种边界情况，永远得靠你主动 trim 或正则兜底。