Java多行输入读取方法详解

Java命令行多行输入看似简单，实则暗藏陷阱：Scanner因nextXXX()方法残留换行符导致nextLine()“跳过”首行、交互式输入卡死在hasNextLine()、中文乱码源于终端与JVM编码不一致、不同运行环境（终端/重定向/IDE）行为差异巨大——本文直击这些高频痛点，给出可落地的解决方案：统一用nextLine()后手动类型转换、显式指定字符集、优先选用更稳定高效的BufferedReader，并强调边界控制才是多行输入真正的核心挑战。

Scanner.nextLine() 为什么只读了一行就结束了？

因为 nextLine() 在遇到前一个 nextInt()、nextDouble() 等方法留下的换行符时，会立刻返回空字符串——这不是 bug，是 Scanner 的缓冲区行为。它把回车当成了“已输入”，直接消费掉了。

常见错误现象：nextInt() 读年龄后，紧接着 nextLine() 读姓名，结果姓名为空；或者循环里每次 nextLine() 都跳过第一轮。

• 用 nextLine() 前，先调一次 nextLine() 吃掉残留换行符（最简单但易忘）
• 统一用 nextLine() 读所有输入，再手动转类型，比如 Integer.parseInt(line)
• 别混用 nextXXX() 和 nextLine()，尤其在循环中

while (scanner.hasNextLine()) 循环卡死怎么办？

这个判断本身不会卡死，但用户没按约定结束输入时，程序就一直等。命令行没有“文件结束”概念，得靠人来触发——Windows 是 Ctrl+Z 回车，macOS/Linux 是 Ctrl+D。

使用场景：读配置块、多行日志、CSV 片段等不确定行数的输入。

• 如果想用特定字符串（如 "END"）结束，就别用 hasNextLine()，改用 while (true) + if ("END".equals(line)) break
• hasNextLine() 在标准输入被重定向时才真正可靠（比如 java Main < input.txt）
• 交互式运行时，记得告诉用户怎么终止，否则看起来像卡住

中文输入乱码或读不到字？

不是 Scanner 的问题，是终端编码和 JVM 启动参数不一致导致的。Windows cmd 默认 GBK，而 Java 8+ 默认用 UTF-8 解析 stdin。

错误信息示例：????、空行、InputMismatchException（其实是字节错位引发的解析失败）

• Windows 下运行加参数：java -Dfile.encoding=GBK Main
• macOS/Linux 一般没问题，但若终端设为 GBK，也要同步 JVM 编码
• 更稳的做法：用 new Scanner(System.in, "GBK") 显式指定编码（注意第二个参数是字符集名）

用 BufferedReader 替代 Scanner 更合适吗？

是的，尤其对纯文本多行输入。BufferedReader 没有 token 解析逻辑，不吞换行符，也不做类型转换，更可控、更快。

性能影响：读千行以上文本时，BufferedReader 比 Scanner 快 2–3 倍；兼容性上，它从 Java 1.1 就存在，无版本顾虑。

• 初始化：BufferedReader reader = new BufferedReader(new InputStreamReader(System.in, "UTF-8"))
• 读取循环：String line; + while ((line = reader.readLine()) != null)
• 注意：readLine() 返回 null 表示流结束（Ctrl+D / Ctrl+Z），不是空行

多行输入真正的复杂点不在语法，而在输入源的边界控制——终端、重定向、管道、IDE 控制台各自行为不同，同一段代码在不同环境可能表现不一。别假设用户一定知道怎么发 EOF。

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