nextLine() 读空行是因 nextInt() 留下换行符；应在其后加 nextLine() 吃掉，或统一用 nextLine() 配合 parseInt/trim；读整行必选 nextLine()；Scanner 应全局唯一，避免重复创建；nextLine() 跨平台兼容换行符。
nextLine() 读到空行或跳过输入，是因为 nextInt() 留下了换行符
这是最常踩的坑：用 nextInt() 读数字后直接跟 nextLine()，结果后者立刻返回空字符串。因为 nextInt() 只消费数字，不消费回车符，那个残留的 \n 被 nextLine() 当作“空行”直接吞掉。
实操建议：
- 在
nextInt()（或nextDouble()、nextBoolean()等非nextLine()方法）之后，加一句scanner.nextLine()专门吃掉换行符 - 或者统一用
nextLine()读所有输入，再手动解析数字，比如Integer.parseInt(scanner.nextLine().trim()) - 注意
trim()很关键——用户可能输完数字多按了空格或 Tab，不 trim 容易抛NumberFormatException
想读一行带空格的字符串，就只用 nextLine()，别混用 next()
next() 遇到空格/制表符/换行就停，根本读不到完整句子；而 nextLine() 的设计目标就是读到换行符为止，天然支持空格、中文、标点、前后空格等所有字符。
常见错误现象：用户输入 hello world，用 next() 只拿到 hello，第二遍调用又卡住等新输入——这不是 bug，是它本来的行为。
实操建议：
- 只要需求是“整行”，无条件选
nextLine() - 如果需要分割单词，后续用
split(" ")或StringTokenizer处理，别指望 Scanner 替你分 - 注意
nextLine()返回的是包含前后空白的原始字符串，是否trim()取决于业务逻辑（比如用户名不允许首尾空格，就必须 trim）
Scanner 没关闭或重复创建，会导致输入流异常或阻塞
多次 new Scanner(System.in) 是危险操作：底层 System.in 是单例 InputStream，第二次 new 会把前一个 Scanner 关联的流置为 closed 状态，再调 nextLine() 就抛 IllegalStateException: Scanner closed。
分析 Java Spring Boot 后端 Controller 代码，自动生成 Markdown 格式的接口文档。当用户说“生成 Java 接口文档”、“生成 API 文档”、“从 Spring 代码生成文档”时触发。
实操建议：
- 全局只持有一个
Scanner实例，比如声明为static final Scanner scanner = new Scanner(System.in) - 不要在方法里反复 new Scanner(System.in)，尤其别放在循环内
- 程序退出前可以调
scanner.close()，但注意关了就不能再读——交互式程序通常不关，让 JVM 自动回收
nextLine() 在 Windows 和 Linux 下换行符兼容性没问题
有人担心 \r\n vs \n 会影响 nextLine()，其实完全不必：Scanner 的 nextLine() 内部用 hasNextLine() 判断时，已自动适配所有平台的行终止符（\n、、\r），返回的字符串也不含任何换行符。
唯一要注意的是：如果你自己用 BufferedReader.readLine()，行为一致；但若用 InputStreamReader + 手动 read 字节，就得自己处理换行符差异。
所以，放心用 nextLine()，它比你想象中更健壮——复杂点在于输入顺序和 Scanner 生命周期管理，而不是跨平台问题。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
