Java正则关键在Pattern编译、Matcher状态管理及边界语义：Matcher必须每次重新获取；matches()要求全匹配，find()查任意子串，lookingAt()仅开头匹配；量词影响回溯行为；默认不支持Unicode需显式启用标志。
Java 正则表达式不是“写对就能用”，关键在 Pattern 编译行为、Matcher 状态管理和匹配边界语义——不理解这些，find() 返回 false 或 group() 抛 IllegalStateException 就是常态。
为什么 Pattern.compile() 后必须用 matcher() 获取新 Matcher 实例
Matcher 是有状态对象，每次调用 find()、matches() 会移动内部指针；复用同一个 Matcher 对不同字符串匹配，结果不可靠。
- 错误做法：
Pattern p = Pattern.compile("\d+"); Matcher m = p.matcher("123"); m.find(); // true m = p.matcher("abc"); // 必须重新 matcher()，不能 m.reset("abc") m.find(); // false —— 但你以为只是没匹配到，其实上一次状态可能干扰 - 正确做法：每次匹配前都调用
p.matcher(input)，哪怕input是同一个字符串 - 性能提示：如果正则固定且高频使用，
Pattern可静态缓存（线程安全），但Matcher绝对不能缓存复用
matches() vs find() vs lookingAt() 的本质区别
三者不只语义不同，底层锚定逻辑也不同，选错会导致漏匹配或误判。
-
matches()：等价于^pattern$，要求整个输入序列完全匹配，开头结尾都被锚定 -
find()：在输入中查找**任意位置**的子串匹配，不强制占满全文 -
lookingAt()：只从**字符串开头**尝试匹配，不要求结尾，等价于^pattern - 常见陷阱：
"123abc".matches("\d+")→false（因为没吃掉"abc"），但find()就是true
贪婪、勉强、占有量词的实际影响与调试方法
量词后缀（?、+）不只改匹配长度，更决定回溯行为——尤其在嵌套或长文本中，可能引发灾难性回溯（Catastrophic Backtracking）。
立即学习“Java免费学习笔记（深入）”；
-
.*（贪婪）：尽可能多匹配，失败时逐步回退 -
.*?（勉强）：尽可能少匹配，找到第一个满足后续条件的位置就停 -
.*+（占有）：匹配后绝不回退，适合已知无歧义场景，但错误使用会直接导致匹配失败 - 调试建议：用
Pattern.compile(pattern, Pattern.DOTALL)配合短输入测试，观察group(0)内容；怀疑回溯时，把.*拆成更具体的字符类（如[^\r\n]*）
Unicode 和 String 边界问题：为什么 \b 在中文里经常失效
\b 是单词边界，定义为“一边是 \w（ASCII 字母/数字/下划线），另一边不是”。它默认不识别中文、日文等 Unicode 字符作为“字”，所以 "测试123".replaceAll("\b\d+\b", "X") 不会替换 "123"。
- 解决方式一：显式启用 Unicode 字符类，加
Pattern.UNICODE_CHARACTER_CLASS标志：Pattern p = Pattern.compile("\b\d+\b", Pattern.UNICODE_CHARACTER_CLASS); - 解决方式二：不用
\b，改用环视：(?（更精确，但稍重） - 注意：
\w默认也不匹配中文，需配合UNICODE_CHARACTER_CLASS才能识别\p{IsAlphabetic}类字符
真正卡住人的往往不是语法写不对，而是 Matcher 的可变状态、量词的隐式回溯路径、以及 \b 这类“看起来通用实则 ASCII 限定”的元字符。写完正则别急着上线，用边界输入（空串、纯符号、混排 Unicode）跑一遍 find() 和 groupCount()。
