JavaScanner输入获取方法全解析

本文深入剖析了Java中Scanner类在实际使用中最常遇到的四大痛点：换行符残留导致nextLine()读取为空、中文输入因编码不一致引发乱码或卡死、误调close()后无法继续读取标准输入，以及文件读取时性能远逊于BufferedReader；不仅清晰解释了每种现象背后的底层机制（如nextInt()不消费换行符、System.in被关闭的连锁影响、平台编码与IDE终端编码错配等），更提供了即插即用的解决方案——从手动清缓存、显式指定UTF-8编码、合理管控Scanner生命周期，到按场景选择更高效的IO工具，真正帮开发者避开那些看似诡异、实则规律可循的“坑”。

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 是纯流式读行，几乎没有额外开销。

• 适用场景：Scanner 适合交互式输入、格式简单且需混合类型解析（如 “name=Tom age=25”）；文件批量读取优先选 BufferedReader
• 性能差异：读万行文本，Scanner 可能慢 2–5 倍，尤其开启正则分隔符（默认空白符）时
• 小技巧：如果坚持用 Scanner 读文件，构造时传入 BufferedReader 包装过的流，能略微缓解缓冲不足问题：

  new Scanner(new BufferedReader(new FileReader("a.txt")))

实际写控制台交互时，最麻烦的不是语法，而是换行符残留和编码错位——这两个点不提前踩一遍，调试时会反复怀疑是不是自己手抖打错了。

以上就是《JavaScanner输入获取方法全解析》的详细内容，更多关于的资料请关注golang学习网公众号！