Java正则匹配失败多因模式与输入结构不匹配或忽略转义、边界、贪婪等规则；String.matches()要求全串匹配，检测子串应改用find()；高频调用需复用Pattern实例。
Java 正则表达式不是“写一次就跑通”的工具，它依赖 Pattern 编译行为、Matcher 匹配状态和字符串实际内容三者严格对齐；多数失败不是语法错，而是匹配模式与输入结构不匹配，或未正确处理转义、边界、贪婪等隐性规则。
为什么 String.matches() 总是返回 false？
这个方法要求整个字符串完全匹配正则，而不是“包含”某个子串。比如 "abc123".matches("\\d+") 是 false，因为开头的 "abc" 不符合 \\d+；它等价于用 ^...$ 包裹你的正则。
- 想检测是否“包含”数字：改用
Pattern.compile("\\d+").matcher(str).find() - 想验证邮箱格式（整串合法）：用
matches()可以，但正则必须覆盖完整结构，例如"^[A-Za-z0-9._%+-]+@[A-Za-z0-9.-]+\\.[A-Za-z]{2,}$" - 注意
matches()会隐式编译正则，高频调用时建议复用Pattern实例
Pattern.compile() 的 flag 怎么选？
常见 flag 直接改变匹配语义，不是可有可无的修饰。比如 Pattern.CASE_INSENSITIVE 让 [a-z] 同时匹配大写，而 Pattern.DOTALL 让 . 匹配换行符 —— 默认不匹配，所以跨行提取文本时若没加它，.*? 会在第一行末就停止。
-
Pattern.MULTILINE：让^和$分别匹配每行起止，而非整个字符串首尾 - 多个 flag 用
|连接：Pattern.compile("foo", Pattern.CASE_INSENSITIVE | Pattern.UNICODE_CASE) -
Pattern.LITERAL会忽略所有元字符含义，适合拼接用户输入的字面量（如搜索关键词），但此时不能用.*等功能
替换操作中 $1、$0 是什么？为什么有时报错？
在 在 Matcher.replaceAll() 或 String.replaceAll() 的 replacement 字符串里，$n 引用第 n 个捕获组，Matcher.replaceAll() 或 String.replaceAll() 的 replacement 字符串里，$n 引用第 n 个捕获组，$0 是整个匹配项。但它们不是变量，是被引擎识别的特殊占位符；如果 replacement 里误写成 "\$1"（多加了反斜杠），或者正则根本没定义 () 捕获组，就会原样输出 $1 或抛 IllegalArgumentException。"$1"（多加了反斜杠），或者正则根本没定义 () 捕获组，就会原样输出 或抛 IllegalArgumentException。
立即学习“Java免费学习笔记（深入）”；
- 要字面量输出
$，得写成"\\$"（Java 字符串里反斜杠需双写） - 用
Matcher.appendReplacement()+appendTail()可精细控制替换逻辑，避免一次性全量替换带来的意外 - 注意
replaceAll()中的 replacement 不支持${name}命名组引用，只认数字索引
性能陷阱：为什么正则突然变慢甚至卡死？
典型原因是回溯爆炸（catastrophic backtracking），尤其出现在嵌套量词组合时，比如 (a+)+b 匹配一长串 a 而结尾没有 b。JVM 的 Pattern 引擎是 NFA 实现，对某些病态正则会指数级尝试分支。
- 避免
.*后紧跟另一个可变长度模式，如.*\\d.*→ 改用.*?\\d（非贪婪）或更精确锚定 - 用
Pattern.compile()配合matcher().usePattern()复用已编译对象，减少重复编译开销 - 对不可信输入（如用户提交的搜索词），先用
Pattern.quote()转义再拼入正则，防止注入恶意模式
真正难的不是写出能匹配的正则，而是写出**只匹配想要内容、不匹配不想要内容、且不会在边界 case 下失控**的正则。每次改完都该用几组典型 + 边界输入（空串、null、超长文本、含换行/unicode 字符）验证行为，而不是只靠一个“看起来对”的例子。
