这是换行符残留问题：nextInt()不读取换行符，导致nextLine()立即返回空字符串；正确做法是调用scanner.nextLine()手动清除残留换行符。
Scanner用nextInt()后nextLine()读不到内容
这是最典型的换行符残留问题：调用nextInt()、nextDouble()等方法不会消费输入末尾的换行符，导致紧接着的nextLine()立刻读到空字符串。
- 现象：用户输入
123↵abc↵，nextInt()取走123，nextLine()返回空串，而不是"abc" - 本质：
nextInt()只读数字，停在换行符前；nextLine()从当前位置开始读，遇到第一个\n就结束，所以得到空行 - 别用
nextLine().trim()硬扛——它解决不了“根本没读到后续输入”这个事实 - 正确做法是手动吃掉残留换行符：
scanner.nextLine();（单独一行，不赋值）
next()和nextLine()对空白的处理差异
next()跳过开头所有空白（空格、tab、换行），读到下一个空白为止；nextLine()读整行，包括开头空格，但不包含换行符本身。
- 输入
hello world↵（前面两个空格）：next()返回"hello"，nextLine()返回" hello world" - 如果真要读带前导空格的一整行，必须用
nextLine()；若用next()，永远得不到开头空格 - 注意
nextLine()在缓冲区为空时会阻塞等待，不是“跳过”，这点常被误以为是bug
用hasNextLine()预防NoSuchElementException
当输入流提前关闭（比如重定向文件末尾、管道断开），或用户直接按Ctrl+D/Ctrl+Z时，nextLine()会抛NoSuchElementException。
- 不能靠try-catch兜底——这掩盖了真正的输入异常，比如本该有数据却没了
- 必须先用
hasNextLine()判断是否有下一行，再调用nextLine() - 注意：
hasNextLine()不消耗输入，可安全多次调用；但hasNext()和hasNextInt()等方法可能触发阻塞等待，行为不一致 - 示例：
if (scanner.hasNextLine()) {<br> String line = scanner.nextLine();<br>}
Scanner不是线程安全的，别共享实例
多个线程共用一个Scanner对象，即使加锁也容易因内部缓冲区错乱导致nextLine()返回截断或错位内容。
- 常见错误：把
Scanner作为static字段，在工具类里复用 - 后果：A线程刚调完
nextInt()，B线程插进来调nextLine()，结果读到A残留的半截输入 - 建议：每个需要读输入的逻辑，自己创建
Scanner（如new Scanner(System.in)），用完不close（System.in不能关） - 如果封装成方法，参数传
Scanner比用全局实例更可控
换行符清理不是加一行nextLine()就能一劳永逸的事——它依赖你清楚知道上一个读取操作停在哪、缓冲区当前状态如何。很多人卡住，是因为把Scanner当成纯“字符串切片工具”，忽略了它背后是流式字节读取 + 内部指针移动的真实机制。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
