发布于2026-07-10 阅读(0)
扫一扫,手机访问

hasNextInt() 只做一件事:看一下下一个 token 能不能解析成 int。但它看完就走,不消费输入流——光标还停在原地。这本身没什么问题,但一旦你后续调用 nextInt(),它会去取那个 token,中间如果混了别的 nextXXX()(比如 nextLine()),换行符残留就会跳出来捣乱。
最常见的一个翻车场景:hasNextInt() 明明返回了 true,但接下来的 nextInt() 却抛出 InputMismatchException。追根溯源,往往是因为前一次 nextLine() 留下的换行符没被吃掉,nextInt() 又不负责擦屁股,于是下一次 nextLine() 直接返回空字符串,逻辑全乱套。
"123abc" 会被当作整数,因为 hasNextInt() 只检查 token 开头有没有数字。"123,456" 时,"123," 不会被识别为 int——因为逗号不是分隔符,而是 token 的一部分。"2147483648"(超出 Integer.MAX_VALUE)会返回 false,"-2147483649" 也返回 false,但你没法区分是格式不合法还是数值越界。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() 是基于 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%,但对终端交互场景几乎无感,不用太在意。Scanner 在输入流关闭后调用 hasNextInt() 可能抛 IllegalStateException,最好包在 try-catch 里。实际用的时候,最容易被忽略的是:你以为 hasNextInt() 帮你挡住了所有非数字输入,结果用户输了个 "123 "(带空格)你 happily 接收了,后面逻辑却因为多出的空格崩了——这种边界情况,永远得靠你主动 trim 或正则兜底。
售后无忧
立即购买>office旗舰店
售后无忧
立即购买>office旗舰店
售后无忧
立即购买>office旗舰店
售后无忧
立即购买>office旗舰店
正版软件
正版软件
正版软件
正版软件
正版软件
1
2
3
7
8