Scanner.next(Pattern)本质是跳过前导分隔符后贪婪匹配最长前缀，不消费后续字符，失败抛NoSuchElementException；非全匹配需手动校验+回退或改用nextLine()配合matches()。
Scanner.next(Pattern) 的匹配行为本质是「跳过前导分隔符后贪婪匹配」
它不会等待用户输入“刚好符合正则”的字符串，而是从当前扫描位置开始，跳过 Scanner 默认的分隔符（如空格、换行等），然后尝试用传入的 Pattern 匹配**尽可能长的前缀**。如果匹配失败，直接抛出 NoSuchElementException；如果成功，光标停在匹配结束处，**不消费后续字符**（哪怕它们也符合模式）。
这意味着：next(Pattern) 不是“校验式读取”，而是“提取式匹配”——它假设输入流里确实存在能被该模式覆盖的片段，且你接受它只取其中最长合法前缀。
- 常见错误现象：
scanner.next(Pattern.compile("\d+"))遇到输入"123abc"会返回"123"，而非报错或等待重输 - 若输入为
"abc123"（开头无数字），则抛NoSuchElementException，因为跳过分隔符后第一个字符就不满足\d - 它不等价于「先读整个 token 再用正则校验」，无法实现“非全匹配即重试”的交互逻辑
想实现「仅当整 token 完全匹配才接受」必须手动校验 + 回退
next() 或 nextLine() 先读原始字符串，再用 Pattern.matcher(str).matches() 判断是否全匹配。若失败，需把刚读的 token “还回去”——但 Scanner 没有标准回退 API，只能靠 useDelimiter 配合 hasNext 循环探测，或改用更可控的输入方式。
- 安全做法：用
scanner.hasNextLine()+scanner.nextLine()读整行，再用pattern.matcher(line).matches()校验 - 若坚持用
next()流程，可临时将分隔符设为"\A"（行首锚点），再用hasNext(pattern)探测，但需注意这会影响后续所有next*调用 - 性能影响：每次校验都是新创建
Matcher，对高频输入无明显负担；但反复nextLine()+ 丢弃会增加 GC 压力
用 Scanner.findInLine() 替代 next(Pattern) 实现「行内按需提取」
当你要从一行中提取符合某模式的子串（不要求是完整 token），findInLine(Pattern) 更合适：它在当前行剩余部分搜索第一个匹配，返回 String 或 null，且不移动 scanner 的行位置（下次 nextLine() 仍读同一行）。
- 使用场景：解析日志行中嵌入的时间戳
findInLine(Pattern.compile("\d{4}-\d{2}-\d{2} \d{2}:\d{2}:\d{2}")) - 与
next(Pattern)关键区别：findInLine不依赖分隔符，不消费未匹配字符，失败不抛异常 - 注意：它只搜当前行，遇到换行就停止；若需跨行匹配，得自己拼接多行文本
真正需要「阻塞等待合法输入」时，别硬套 next(Pattern) —— 改用循环 + 明确提示
交互式程序中，用户输错应提示重输，而不是让 Scanner 抛异常中断流程。此时 next(Pattern) 的设计初衷（快速提取已知格式数据）反而成了障碍。
- 实操建议：用
scanner.nextLine()读，pattern.matcher(input).matches()校验，失败则System.out.println("请输入纯数字")并 continue - 避免陷阱：不要用
scanner.next()后跟scanner.nextLine()清缓冲区——这会吞掉下一行首段内容；统一用nextLine()可规避 - 兼容性提醒：Java 9+ 中
Scanner对 Unicode 分隔符支持更好，但next(Pattern)行为未变，别指望它自动处理 emoji 或零宽空格
正则匹配和输入控制是两层事：next(Pattern) 解决“怎么切”，而“要不要切、切错了怎么办”得由你用循环和条件自己兜底。漏掉这点，八成会在用户输个空格就崩掉。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
