scanner.nextline() 读不到输入是因为前序的 nextint() 等方法未消费换行符，导致 nextline() 立即读取空字符串；应在其后加 scanner.nextline() 清缓存，或统一用 nextline() 配合 parsexxx 转型。
Scanner.nextLine() 为什么总读不到输入？
因为 nextLine() 会消费换行符，而它前面如果用了 nextInt()、nextDouble() 等非行读取方法，这些方法不会吃掉用户按下的回车，导致 nextLine() 立刻读到一个空字符串。
- 场景：先用
nextInt()读年龄，再用nextLine()读姓名，结果姓名为空 - 解决：在
nextInt()后加一句scanner.nextLine()手动清掉残留换行符 - 更稳的做法：统一用
nextLine()读所有输入，再用Integer.parseInt()或Double.parseDouble()转类型
中文输入乱码或卡住怎么办？
默认 Scanner 使用系统平台编码（Windows 上常是 GBK），但 IDE 控制台（如 IntelliJ 或 VS Code 的终端）可能以 UTF-8 启动，编码不一致就会丢字、显示问号甚至阻塞。
- 验证方式：输入“你好”，输出变成 “ ” 或直接没响应
- 修复：显式指定编码，构造时传入
System.in和"UTF-8"：Scanner scanner = new Scanner(System.in, "UTF-8");
- 注意：JDK 17+ 在某些 Windows 终端下仍可能 fallback 到 CP65001，若仍异常，可临时改用
"GBK"测试是否为编码问题
Scanner 关闭后还能不能继续用？
不能。调用 scanner.close() 会连带关闭底层的 System.in，后续任何对 System.in 的读取（包括新建另一个 Scanner）都会抛 java.util.NoSuchElementException 或直接阻塞。
- 常见错误：在方法末尾无脑
close()，然后主流程又想读下一轮输入 - 建议：除非明确整个程序不会再读标准输入，否则不要 close Scanner
- 替代方案：把 Scanner 声明为类字段，或用 try-with-resources 仅包裹单次输入块（需确保该块内完成全部读取）
读取文件时 Scanner 比 BufferedReader 慢很多？
是的。Scanner 是面向「解析」设计的，自带词法分析、类型转换、分隔符切分逻辑；而 BufferedReader 是纯流式读行，几乎没有额外开销。
立即学习“Java免费学习笔记（深入）”；
- 适用场景：Scanner 适合交互式输入、格式简单且需混合类型解析（如 “name=Tom age=25”）；文件批量读取优先选
BufferedReader - 性能差异：读万行文本，Scanner 可能慢 2–5 倍，尤其开启正则分隔符（默认空白符）时
- 小技巧：如果坚持用 Scanner 读文件，构造时传入
BufferedReader包装过的流，能略微缓解缓冲不足问题：new Scanner(new BufferedReader(new FileReader("a.txt")))
