inputmismatchexception 是 scanner 在调用 nextint() 等方法时因输入无法解析为指定类型而抛出的运行时异常；需在 catch 中调用 next() 或 nextline() 清除缓冲区残留数据，否则重复报错。
InputMismatchException 是 Scanner 读取类型不匹配时抛出的运行时异常
它不是编译错误，而是在调用 nextInt()、nextDouble() 等强转方法时，输入内容无法解析为对应类型才触发。比如用户输了个 "abc" 却调用 scanner.nextInt()，就会立刻抛出这个异常，程序中断——除非你主动捕获。
为什么 try-catch 之后还要调用 scanner.next()？
很多人 catch 住异常就完事了，结果下一次读取还是报同样的错。这是因为 Scanner 的内部指针没动：非法输入仍留在缓冲区里，下次调用 nextInt() 会再次尝试解析它。
- 必须在
catch块里显式调用scanner.next()（或scanner.nextLine()）把坏数据“吃掉” - 用
next()只跳过当前 token（空格分隔的一段），用nextLine()会清空整行剩余内容（含换行符） - 如果后续要读整行字符串，优先用
nextLine()；如果继续读数字，next()更安全，避免吞掉本该属于下一次读取的换行
nextInt() 和 nextLine() 混用导致漏读的典型陷阱
这是和 InputMismatchException 经常一起出现的“连带问题”。比如先调 nextInt() 再调 nextLine()，后者会直接返回空字符串——因为 nextInt() 不消费换行符，nextLine() 立刻读到它就结束了。
- 修复方式：在
nextInt()后加一句scanner.nextLine()手动清理换行符 - 更稳妥的做法是统一用
nextLine()读所有输入，再用Integer.parseInt()或Double.parseDouble()转换，这样异常类型变成NumberFormatException，但缓冲区行为完全可控 - 注意：
parseInt()和parseDouble()不会自动跳过空白，输入前后有空格会直接抛NumberFormatException
用 hasNextXxx() 预检能避免异常，但要注意语义边界
hasNextInt() 这类方法看起来很安全，但它只检查“下一个 token 是否能被解析为 int”，并不等于“接下来就是用户想输的整数”。比如输入 "123abc"，hasNextInt() 返回 true，但 nextInt() 会读出 123，把 "abc" 留在缓冲区——这可能破坏后续逻辑。
立即学习“Java免费学习笔记（深入）”；
-
hasNextXxx()对纯数字输入有效，但对混合输入（如带单位的"5kg"）不可靠 - 它不能替代输入校验，也不能解决用户误输后如何恢复的问题
- 若需严格格式（如“只能输一个整数，后面不能跟别的字符”），必须用
nextLine()+ 正则或trim()+parseInt()组合
真正麻烦的从来不是异常本身，而是 Scanner 缓冲区状态的隐式变化——它不报错时很顺，一出错就卡在看不见的地方。每次调用 nextXxx() 前，都得心里默念：指针在哪？换行还在不在？上一个坏输入清干净没？
