Scanner.nextLine() 读一行即结束是因前序 nextInt() 等方法残留换行符被其立即消费；应统一用 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 片段等不确定行数的输入。
立即学习“Java免费学习笔记（深入）”；
java-api-doc-generator
下载
分析 Java Spring Boot 后端 Controller 代码，自动生成 Markdown 格式的接口文档。当用户说“生成 Java 接口文档”、“生成 API 文档”、“从 Spring 代码生成文档”时触发。
- 如果想用特定字符串（如
"END"）结束，就别用hasNextLine()，改用while (true)+if ("END".equals(line)) break -
hasNextLine()在标准输入被重定向时才真正可靠（比如java Main ） - 交互式运行时，记得告诉用户怎么终止，否则看起来像卡住
中文输入乱码或读不到字？
不是 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），不是空行
