Pattern.compile()需预编译正则以提升性能并支持复用、子串查找及分组提取；直接使用静态matches()会重复编译且仅支持全串匹配；Matcher需先调find()/matches()再取group()，否则抛IllegalStateException。
Pattern.compile() 为什么不能直接用字符串匹配
因为 Pattern 是正则表达式的编译结果，不是执行器。直接拿字符串调 matches() 看似方便，但每次都会隐式重新编译，性能差且无法复用。尤其在循环里反复匹配同一类格式（比如校验手机号、邮箱），必须先用 Pattern.compile() 编译一次，再通过 matcher() 获取 Matcher 实例。
常见错误：写成 Pattern.matches("\\d+", "123") —— 这个静态方法内部确实会编译，但无法缓存；更糟的是它只支持全串匹配，不支持查找子串或分组提取。
- 编译后可复用：
Pattern pattern = Pattern.compile("\\b\\w+@\\w+\\.\\w+\\b"); - 区分用途：
pattern.matcher(text).find()用于查找子串，.matches()用于整串匹配 - 注意转义：Java 字符串里反斜杠要写两层，
"\\d"才表示正则中的\d
Matcher.find() 和 Matcher.matches() 的行为差异
matches() 要求整个输入序列完全匹配正则，等价于在正则前后自动加了 ^ 和 $；而 find() 只要在任意位置找到符合的部分就返回 true，适合从文本中抽字段。
典型误用场景：想从日志行里提取 IP 地址，却用了 matcher.matches()，结果永远 false —— 因为整行不是纯 IP。
立即学习“Java免费学习笔记（深入）”；
- 提取多个匹配项：循环调
find()，再用group()或group(1)拿捕获内容 - 验证格式用
matches()，比如"13812345678".matches("1[3-9]\\d{9}") -
lookingAt()是介于两者之间：从头开始匹配，但不要求到末尾
Matcher.group() 报 java.lang.IllegalStateException 怎么办
这个异常只在一个前提下抛出：没成功调用过 find()、matches() 或 lookingAt() 就直接访问分组。Matcher 不是“即查即得”，它维护一个内部状态，必须先执行匹配动作，才有分组数据可取。
最容易忽略的点：find() 返回 boolean，很多人忘了判断就直接 group()，导致运行时报错。
- 安全写法：
if (matcher.find()) { String ip = matcher.group(1); } - 分组编号从 1 开始，
group(0)是整个匹配串，group(1)是第一个()里的内容 - 如果正则里有可选分组（比如
(\\d+)?），对应group(n)可能返回null，别直接 toString()
如何避免 Pattern 编译失败或回溯爆炸
Pattern.compile() 在语法错误时抛 PatternSyntaxException，但更隐蔽的问题是「灾难性回溯」—— 比如 (a+)+b 配对长字符串时 CPU 直接拉满。这不是 Java Bug，是正则引擎特性，但写法不当极易触发。
真实项目里见过因一个未限制长度的 .* 加嵌套量词，导致接口响应从 5ms 延迟到 3s+。
- 优先用明确边界：把
.*换成[^\\n]*或\\w+等更严格的字符类 - 避免嵌套量词：
(a+)+→ 改成a+；(\\d+)*→ 明确最大重复次数，如(\\d{1,3}\\.){3}\\d{1,3} - 敏感场景加超时：JDK 9+ 可用
Pattern.compile(regex, Pattern.CANON_EQ | Pattern.UNICODE_CASE)，但无内置超时，需靠外部线程中断或用Matcher.hitEnd()辅助判断
