scanner读int/double后卡住是因nextline()与nextint()/nextdouble()混用导致换行符残留；应统一用nextline()后解析，或在nextxxx后加nextline()清理；中文乱码需显式指定编码如new scanner(system.in, "utf-8")。
Scanner读int或double时卡住不继续？
这是因为nextLine()和nextInt()/nextDouble()混用后，换行符没被消费掉。比如先调nextInt()读数字，再调nextLine()读字符串，后者会立刻返回空字符串——它其实读到了前面留下的回车。
- 统一用
nextLine()读所有输入，再手动解析：Integer.parseInt(scanner.nextLine()) - 如果坚持用
nextInt()，之后加一句scanner.nextLine()清掉换行符 - 别在循环里反复创建
Scanner对象，一个System.in只能配一个Scanner，否则后续读取会失效
Scanner遇到中文乱码或跳过输入？
默认编码取决于JVM启动环境，Windows上常是GBK，但IDE或终端可能是UTF-8。Scanner本身不处理编码转换，它依赖底层InputStream的字节流解读方式。
- 显式指定编码：用
new Scanner(System.in, "UTF-8")（推荐） - 确保终端/IDE控制台编码与构造参数一致，IntelliJ需在
Help → Edit Custom VM Options加-Dfile.encoding=UTF-8 - 避免用
System.setIn()中途切换输入源，容易导致缓冲区错位
用hasNextXxx()判断输入类型却一直阻塞？
hasNextInt()这类方法在流未结束且无匹配输入时会**等待用户敲回车**，不是立即返回false。它只检查“当前可读token是否符合类型”，不等于“下一个字符是不是数字”。
- 如果想非阻塞探测，得配合
hasNext()+next()+ 正则或异常捕获来模拟 - 真实场景中更稳妥的做法是：先
nextLine()读整行，再用Integer.valueOf()等尝试解析，捕获NumberFormatException -
hasNext()在输入流关闭前永远为true，除非显式调用close()或底层流已EOF
Scanner.close()后还能不能继续读？
不能。调用close()会同时关闭其包装的System.in，后续任何对System.in的读取（包括新建Scanner）都会抛IllegalStateException: Scanner closed或直接失败。
立即学习“Java免费学习笔记（深入）”；
- 除非明确要终止整个输入流程，否则不要轻易
close()基于System.in的Scanner - 若需分阶段读取，用同一个Scanner实例，通过不同
nextXxx()方法切换解析逻辑 - 资源真正需要释放的是文件或网络流，控制台输入一般无需主动close
