hasNextDouble()并非万能校验器，它仅判断当前token是否符合Java double字面量语法（如"3.14abc"返回true、"3,14"在US Locale下返回false），不跳过空白、不处理后续字符、不捕获异常；必须配合nextDouble()消费token，否则易死循环；默认受系统Locale影响，多语言输入需显式设scanner.useLocale(Locale.US)；严格校验应改用Double.parseDouble()+try-catch。
Scanner.hasNextDouble() 为什么有时“失效”？
它不是万能的校验器——hasNextDouble() 只检查**当前 token 是否符合 Java 的 double 字面量语法**，不处理后续 token、不跳过空白、也不捕获异常。比如输入 "3.14abc"，它会返回 true（因为前缀 "3.14" 合法）；而输入 "3,14" 或 "1e" 则返回 false。关键点在于：它依赖 Scanner 当前分隔符（默认空白）切出的 token，且只看“能否解析”，不看“是否完整匹配”。
如何避免误判：必须配合 next() 或 nextDouble() 使用
单独调用 hasNextDouble() 后不消费 token，下次再调仍会看到同一个 token，容易陷入死循环或逻辑错位。正确流程是“先判后取”，且要处理取值失败的边界：
- 如果
hasNextDouble()返回true，应立刻调用nextDouble()消费该 token；不能用next()再手动解析，否则重复解析可能出错 - 如果返回
false，必须调用next()跳过非法 token（否则它一直卡在输入流头部，下次hasNextDouble()还是false） - 注意：
hasNextDouble()不会触发InputMismatchException，但nextDouble()会——所以不要绕过hasNextDouble()直接调nextDouble()
while (scanner.hasNext()) {
if (scanner.hasNextDouble()) {
double d = scanner.nextDouble(); // 必须紧跟
System.out.println("Valid: " + d);
} else {
String bad = scanner.next(); // 必须跳过，否则死锁
System.err.println("Invalid token: " + bad);
}
}Locale 导致的隐性失败
hasNextDouble() 默认使用系统 Locale，而小数点符号受 Locale 控制。例如在德语环境（Locale.GERMAN），"3,14" 是合法 double，但 "3.14" 反而不合法。如果你的程序要处理多语言输入，必须显式设置 Scanner 的 Locale：
- 用
scanner.useLocale(Locale.US)强制按英文习惯解析（小数点为.，逗号为千分位） - 否则在非 US Locale 下，
"1.000"可能被当作整数1（因.被视为千分位），而"1,0"才算合法浮点 - 不设置 Locale 时，
hasNextDouble()行为不可移植，本地测试通过，上线就翻车
替代方案：需要严格校验时别依赖 hasNextDouble()
当业务要求“整个输入字符串必须精确匹配一个 double”（比如配置文件某字段、API 参数校验），hasNextDouble() 就不合适了——它不管 token 前后是否有冗余字符。此时应改用正则或 Double.parseDouble() + try-catch：
- 用
scanner.next().matches("-?\d+\.\d+")只是简单匹配，漏掉科学计数法、负零、无穷等合法形式 - 更稳妥的是：
try { Double.parseDouble(token); } catch (NumberFormatException e) { /* 非法 */ } - 注意
parseDouble("3.14abc")会抛异常，而hasNextDouble()对它返回true——这正是两者语义差异的核心
真正难处理的从来不是“怎么读”，而是“怎么定义什么叫合法”。hasNextDouble() 的契约很窄：它只承诺“这个 token 能被 nextDouble() 安全消费”，不承诺格式干净、不承诺无歧义、也不承诺符合你的业务规则。
