nextLine() 是跳过一行的唯一可靠方式，它消费当前行剩余字符及换行符，将指针移至下一行开头；误用 next() 等方法后需额外调用 nextLine() 清理缓冲区残留换行符。
Scanner.nextLine() 是跳过行的唯一可靠方式
Java 的 Scanner 没有 skip() 或 skipLine() 方法，所谓“跳过不需要的行”，本质是读取并丢弃一行内容。直接调用 nextLine() 是最安全、最符合直觉的做法——它会消费掉当前行剩余字符（包括换行符），把指针移到下一行开头。
常见错误是误用 next() 或 nextInt() 后没清理换行符，导致后续 nextLine() 立即返回空字符串。这不是跳过失败，而是缓冲区残留了换行符。
- 如果刚调用过
nextInt()、nextDouble()等非行读取方法，必须紧接着加一次nextLine()来“吃掉”换行符 - 想跳过 3 行？连续调用三次
nextLine()即可，无需额外判断 - 不要用
skip(Pattern)处理换行逻辑——它基于正则匹配，对 的跨平台处理不可靠，且无法保证“跳过一整行”
用 nextLine() 跳过带前导空格或注释的行
实际读配置或解析简单文本时，常需忽略空行、纯空白行或以 # 开头的注释行。这时不能无脑调用 nextLine()，得先检查内容再决定是否丢弃。
典型场景：读取类似 properties 文件的输入，但 Scanner 不自带注释识别能力，得手动过滤。
立即学习“Java免费学习笔记（深入）”；
分析 Java Spring Boot 后端 Controller 代码，自动生成 Markdown 格式的接口文档。当用户说“生成 Java 接口文档”、“生成 API 文档”、“从 Spring 代码生成文档”时触发。
- 每次循环先调用
nextLine()获取整行，再用trim().isEmpty()判断是否为空行 - 用
startsWith("#")或startsWith("//")检查注释（注意：取决于你约定的注释符号） - 避免在
while (scanner.hasNextLine())循环里反复调用nextLine()却不保存结果——容易漏读或死循环 - 示例逻辑：
while (scanner.hasNextLine()) { String line = scanner.nextLine().trim(); if (line.isEmpty() || line.startsWith("#")) continue; // 处理有效行 }
nextLine() 在 Windows / Linux 换行符下的行为一致
nextLine() 内部使用 Pattern.compile("
|[
u2028u2029u0085]") 匹配行结束符，因此能正确识别
（Linux）、
（Windows）、
（旧 Mac）等所有常见换行风格。你不需要为不同系统写分支逻辑。
但要注意：如果你用 new Scanner(new FileInputStream(...)) 且文件编码不是平台默认编码（如 UTF-8 文件在 Windows 上用 GBK 解析），nextLine() 可能因乱码提前截断或读错行边界——这不是跳过逻辑的问题，而是编码配置缺失。
- 始终显式指定编码：
new Scanner(file, "UTF-8") - 不要依赖
System.getProperty("file.encoding")，它不可靠 - 用
scanner.useDelimiter(" ")是危险操作——它会破坏nextLine()的跨平台能力，且无法处理
别用 skip() 试图跳过整行——它不按行工作
skip(Pattern) 的设计目标是跳过**匹配正则的字符序列**，不是“跳过 N 行”。哪怕你传入 skip(.*
)，它也只跳过第一个匹配项，且在多行模式下行为难预测；更糟的是，它不会推进到下一行起始位置，后续 nextLine() 仍可能读到被部分跳过的那行剩余内容。
真实错误现象：scanner.skip(".*\n"); 执行后，下一行 nextLine() 返回的却是空字符串或错位内容——因为 skip() 没有消费换行符后的回车符，也没重置内部行计数器。
-
skip()适合跳过固定前缀（如跳过 "ID:" 字符串），不适合行级控制 - 它不抛异常也不返回跳过长度，失败时静默，极难调试
- 和
hasNextLine()/nextLine()混用极易导致逻辑断裂
nextLine()，用好它，别绕路。最容易被忽略的是——每次调用非 nextLine() 方法后，换行符还留在缓冲区里，它不会自动消失。 
