Java正则需用Pattern.compile()预编译复用，避免字符串matches()重复编译；注意DOTALL与UNICODE_CHARACTER_CLASS组合使用、Unicode匹配需(?U)或显式标志；基础校验优先用EmailValidator等专用工具，正则仅作初步筛选。
Java里用Pattern编译正则，不是直接调字符串方法
Java原生正则能力全靠java.util.regex.Pattern，它不提供静态匹配方法，必须先compile()再用Matcher操作。常见错误是误以为"abc".matches("a.*")这种快捷方式能替代Pattern——它底层确实用了Pattern，但每次调都重新编译，高频场景下性能差、还无法复用预编译逻辑。
真正要用好，得自己管理Pattern实例：
-
Pattern对象线程安全，可缓存复用（比如用static final） - 编译失败抛
PatternSyntaxException，必须捕获或声明 - 区分
Pattern.CASE_INSENSITIVE和Pattern.UNICODE_CASE：后者才支持非ASCII字符大小写（如德语ß）
常用正则类库：Apache Commons Text比Pattern更省事
如果只是做邮箱、手机号、URL等基础校验，别硬写正则。Apache Commons Text的StringSubstitutor不适用，但org.apache.commons.text.matcher.StringMatcher体系也不直接暴露；真正顺手的是commons-validator（虽已归档）或更现代的org.apache.commons.text.TextMatcher——不过当前最稳的选择其实是org.apache.commons.text.StringEscapeUtils之外的RegexUtils（需手动引入）。
更现实的方案：
立即学习“Java免费学习笔记（深入）”；
- 用
org.apache.commons.validator.routines.EmailValidator验证邮箱（注意它依赖commons-validator1.7+） - 用
org.apache.commons.text.similarity.JaccardSimilarity？不，那是相似度，和正则无关 - 实际推荐：
io.github.lukehutch.fast-classpath-scanner？也不是——回到本质：90%场景用Pattern.compile("^[a-zA-Z0-9._%+-]+@[a-zA-Z0-9.-]+\.[a-zA-Z]{2,}$").matcher(input).matches()+ 缓存就够了
Pattern的DOTALL和UNICODE_CHARACTER_CLASS容易踩坑
.默认不匹配换行符，加Pattern.DOTALL才匹配。但很多人不知道：即使开了DOTALL，w、d、s仍按ASCII行为走，除非显式加Pattern.UNICODE_CHARACTER_CLASS（或简写(?U)）。例如w+匹配中文会失败，加(?U)后才支持Unicode字母数字。
组合使用示例：
Pattern p = Pattern.compile("(?U)(?s)hello.*world", Pattern.DOTALL | Pattern.UNICODE_CHARACTER_CLASS);
注意：(?U)必须放在模式开头，否则无效；Pattern.UNICODE_CHARACTER_CLASS在Java 7+才完全生效，旧版本可能漏匹配某些Unicode区块。
别把Pattern当万能过滤器，边界条件得手动处理
正则擅长“是否符合”，不擅长“提取并校验结构”。比如验证IP地址：^((25[0-5]|2[0-4]\d|[01]?\d\d?)\.){3}(25[0-5]|2[0-4]\d|[01]?\d\d?)$看似完美，但无法阻止01.02.03.04这种带前导零的非法格式（虽然某些协议接受，但多数业务要拒绝）。这时得配合Integer.parseInt()逐段转整数再判断范围。
类似情况还有：
- 日期格式（
\d{4}-\d{2}-\d{2}不校验2月30日） - 手机号（中国号段变动快，正则写死
1[3-9]\d{9}会漏19x新号段） - JSON片段提取（用正则解析嵌套结构极易崩溃，该上
JsonParser）
正则只是第一道筛子，关键字段的语义校验绕不开业务代码。
