pattern.compile() 应复用编译后的pattern实例以提升性能，避免string.matches()重复编译；需区分matches()（全匹配）与find()（子串匹配），正确调用group()前必须先find()/matches()，matcher非线程安全且reset()后须重新find()，警惕贪婪匹配导致的回溯爆炸。
Pattern.compile() 为什么不能直接用字符串匹配
因为 Pattern 是正则编译后的不可变对象，String.matches() 每次调用都会隐式重新编译——高频校验场景下性能明显下降。真正该复用的是 Pattern 实例，不是每次 new 一个。
- 校验邮箱、手机号等固定规则时，把
Pattern.compile("^[a-zA-Z0-9._%+-]+@[a-zA-Z0-9.-]+\.[a-zA-Z]{2,}$")提到静态字段或 Spring Bean 初始化里 - 动态拼接正则（比如搜索关键词高亮）必须注意转义：用户输入的
"."要变成"\."，否则会匹配任意字符 -
Pattern.compile()抛出PatternSyntaxException，但很多开发者忽略 try-catch，导致线上遇到非法输入直接崩溃
Matcher.find() vs Matcher.matches() 的语义区别
这两个方法根本不是“全匹配 vs 部分匹配”的简单区分：matches() 要求整个输入序列完全符合模式（等价于 ^...$），而 find() 只要找到子串就返回 true。写错会导致空指针或漏匹配。
- 提取 HTML 中所有
<a href="..."></a>：必须用find()，用matches()永远失败，因为整段 HTML 不可能只包含一个链接 - 校验密码强度（至少 1 个数字 + 1 个大写字母）：适合多次
find()分别查"\d"和"[A-Z]"，而不是硬塞进一个复杂正则 - 调用
group()前必须先调find()或matches()，否则抛IllegalStateException
Matcher.reset() 在循环中容易被忽略的副作用
同一个 Matcher 实例反复用于不同字符串时，不调 reset(input) 会沿用上一次的 region 和 group 状态，结果不可预测。
- 错误写法：
matcher.find()后直接matcher.reset("new text")再find()—— 必须在reset()后重新调find()，否则group()返回空或旧值 - 多线程共用一个
Matcher？绝对不行。Matcher不是线程安全的，要么每次 new，要么用ThreadLocal<matcher></matcher> - 如果只是换输入字符串，更推荐直接
pattern.matcher("new text")，比复用Matcher+reset()更直白少错
贪婪匹配 .* 导致的回溯爆炸风险
当正则含多个 .* 且输入文本超长或不符合预期时，JVM 线程可能卡死在回溯中，CPU 打满，日志里看不到异常，只看到响应超时。
立即学习“Java免费学习笔记（深入）”；
- 提取 JSON 字段值：
"name":"(.*?)"比"name":"(.*)"安全得多，非贪婪量词.*?能显著降低回溯层级 - 避免嵌套量词，比如
(a+)+配合恶意输入"aaaaaaaaX"会触发指数级回溯 - 生产环境建议加超时控制：用
Pattern.compile(..., Pattern.CANON_EQ)无帮助，真正有效的是业务层设置最大匹配长度或用CharSequence.subSequence()截断预处理
正则写得越短，越容易忽略边界 case；真正难的不是写出能跑的表达式，而是想清楚它在 10 万行日志里会不会突然卡住。
