findInLine常返回null，因其仅从当前扫描位置跳过前导空白后尝试匹配一次正则，不回退、不跨行、不重试；若前序操作（如nextInt）使位置停在空白处，且正则未覆盖该位置，则匹配失败。
findInLine 为什么经常返回 null
findInLine 不是“找一行里有没有匹配”，而是“从当前扫描位置开始，跳过前导空白后尝试匹配一次正则；没匹配上就移动到行末，不重试”。如果目标文本不在当前 token 的起始位置（比如前面已有 next() 或 nextInt() 消耗了部分输入），它大概率返回 null。
常见错误现象：scanner.nextInt(); scanner.findInLine("error") 总是 null —— 因为 nextInt() 停在数字后的空白处，而 findInLine 默认不跨空白匹配，且不会回退。
- 使用前确保扫描位置合理：优先用
nextLine()读整行，再对字符串做正则匹配更可控 - 若必须用
findInLine，先调用skip("\s*")清除残留空白 - 它的正则引擎不支持
^或$行锚点（只作用于当前匹配尝试的局部片段）
findInLine 和 findWithinHorizon 的关键区别
两者都做正则查找，但搜索范围和行为逻辑完全不同：findInLine 只在**当前行内**从当前位置向后找一次；findWithinHorizon 在**接下来最多 n 个字符内**查找，可跨行，且会反复尝试直到匹配或超限。
性能影响明显：findWithinHorizon(100) 可能缓存并扫描后续多行内容，而 findInLine 严格限制在单行、单次尝试。
立即学习“Java免费学习笔记（深入）”；
- 查日志中某行内的状态码？用
findInLine("\b200\b") - 查“ERROR”后面紧跟的 5 位数字（可能跨空格甚至换行）？用
findWithinHorizon("ERROR\s+(\d{5})", 200) - 传入的正则若含贪婪量词（如
.*），findWithinHorizon可能吃掉远超预期的字符，导致后续解析错位
正则写法不当导致匹配失败的典型场景
findInLine 底层用的是 java.util.regex，但默认不开启 DOTALL 或 UNICODE_CASE。常见坑是以为 . 能匹配换行——其实不能，因为 findInLine 本身就不跨行，而行内 . 仍不匹配
、
（除非显式加 (?s)）。
错误示例：findInLine("start.*end") 在 "start
end" 上永远失败。
- 需要点号匹配换行？写成
findInLine("(?s)start.*end") - 忽略大小写？用
(?i)error，别依赖useLocale或外部设置 - 避免用
^和$—— 它们在findInLine中等价于A和Z，即整个输入边界，不是行边界
替代方案：什么时候不该用 findInLine
当你要做的不是“在已读入的一行里快速捞一个模式”，而是“解析结构化日志”或“提取多个字段”，硬套 findInLine 会让逻辑脆弱且难调试。它本质是个轻量辅助方法，不是正则解析器。
比如解析 "[INFO] User{id=123, name='Alice'}"，用 findInLine("id=(\d+)") 看似可行，但一旦格式微调（空格增减、引号变化），就挂。
- 固定分隔符数据？优先用
split()+ 字符串操作 - 复杂嵌套或需多次提取？读整行后交给
Pattern.compile(...).matcher(line)多次find() - 要捕获组？
findInLine返回的是匹配的整个字符串，无法直接取 group；必须自己再用Pattern解析一遍
真正容易被忽略的是：Scanner 的内部缓冲区不可见，findInLine 匹配成功后，扫描位置停在匹配末尾，但你没法知道它具体消耗了多少字符——这对后续解析节奏是隐性干扰。
