Scanner.skip(Pattern) 仅在当前位置后、下次读取前生效，需确保未读内容存在且Pattern能匹配，否则抛NoSuchElementException；推荐先用hasNext(Pattern)探测再skip。
Scanner.skip(Pattern) 什么时候真正起作用？
它只在 Scanner 当前位置之后、下一次实际读取（如 next()、nextInt()）之前生效。如果输入流已耗尽，或跳过逻辑没匹配到任何内容且未设 useDelimiter() 配合，调用 skip() 会直接抛 NoSuchElementException —— 这不是 bug，是设计行为。
常见误用场景：想靠 skip() 清掉换行符后接着读字符串，却忘了 nextLine() 本身会吞掉换行，而 skip() 对已读过的字符无能为力。
- 必须确保输入流还有未读内容，且 Pattern 能匹配上（哪怕空字符串也不行，除非 Pattern 显式允许）
- 推荐搭配
hasNext(Pattern)先探测，再 skip，避免异常中断流程 -
skip()不改变 delimiter，它只是“吃掉”匹配的字符；若需全局跳过某类分隔符，应优先考虑useDelimiter()
Pattern 写错导致 skip 完全不生效的典型写法
最常踩的坑是用了贪婪但锚定错误的正则，比如 skip(".*") —— 它会尝试匹配从当前位置到行末所有内容，但默认不跨行，且一旦后面没东西就失败；又或者写成 skip("\s+") 却忘了开头已有换行未被消费，而 \s 默认不含
在某些平台（Windows）可能漏掉
。
- 跨行空白安全写法：
skip("[\s\u200B-\u200F\uFEFF]+")（含零宽空格和 BOM） - 跳过直到下一个非空白字符：
skip("\s*")比"\s+"更鲁棒（允许零长度匹配） - 跳过注释风格噪音（如
# rest of line）：skip("#[^\r\n]*[\r\n]??")，注意??表示懒惰可选换行
和 nextLine() / next() 混用时的顺序陷阱
nextLine() 会消费换行符并返回之前的内容；而 skip() 若放在 nextLine() 之后、下一次读取之前，目标其实是“下一行开头”的噪音 —— 但很多人误以为它能回退清理上一行残留。
在调试 Java 后端 API 故障时使用此技能，尤其适用于以下任务：分析日志、跨 Controller、Service 和 Mapper 层追踪请求、定位异常根因、检查 SQL 执行或参数流转，以及生成简洁的诊断结论与修复方案。
- 错误链路：
nextInt()→ 留下skip("\s+")→nextLine()仍读到空行（因为skip()没匹配到， 还在） - 正确解法：用
skip("\R")（Java 8+ 支持\R匹配任意换行）或直接nextLine()吞掉它 - 更稳做法：统一用
nextLine()读整行，再用String.split()或Pattern.compile().matcher()解析，绕过skip()的状态依赖
性能与替代方案：为什么 skip() 不该用在高频循环里
每次 skip(Pattern) 都会新建 Matcher、重置输入缓冲区位置，内部还涉及 char-by-char 回溯匹配。在解析几千行日志时，比预编译 Pattern + 手动 find() 慢 3–5 倍。
- 高频场景建议：
Pattern whitespace = Pattern.compile("\s*");，然后whitespace.matcher(input).lookingAt()判断并记录 offset - 若只是跳过固定前缀（如 "ID:"），直接用
if (line.startsWith("ID:")) line = line.substring(3);更快更直观 -
skip()真正适合的场景：交互式输入中应对用户随意空格/注释，且每次输入量小、不可预测
它是个精确但脆弱的手术刀，不是扫帚。用之前，先确认你面对的是「不定长、不可控、需正则描述」的噪音，而不是「固定格式、可预判」的结构化输入。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
