String.matches()适合轻量邮箱校验但性能差，推荐使用预编译的Pattern缓存提升性能，工程中应拒绝明显非法格式而非追求RFC 5322全量兼容，需额外处理null、空格、长度等边界情况。
用 String.matches() 做基础邮箱校验
Java 自带的 String.matches() 是最轻量的校验入口，适合快速判断一个字符串是否“看起来像邮箱”。它底层调用 Pattern.matches()，不需预编译，但每次调用都重新解析正则，频繁使用时性能较差。
常见错误是直接套用网上过度简化的正则，比如 "^.+@.+..+$" —— 它会把 "a@b.c"、"@.com" 甚至 "test@@example.com" 都判为合法。实际项目中至少应排除连续 @、开头/结尾为点、连续点等明显非法结构。
推荐一个平衡可读性与实用性的正则：
String emailRegex = "^[A-Za-z0-9._%+-]+@[A-Za-z0-9.-]+\.[A-Za-z]{2,}$";
说明：
立即学习“Java免费学习笔记（深入）”；
-
[A-Za-z0-9._%+-]+：本地部分（@前），允许字母、数字及常见特殊字符，但不允许多余点或连写符号 -
@：必须存在且唯一（正则本身不防多个@，靠前面的字符类限制） -
[A-Za-z0-9.-]+：域名部分，允许点和短横，但不能以点开头/结尾 -
\.[A-Za-z]{2,}：必须有且只有一个点分隔顶级域，且顶级域至少两个纯字母（过滤掉.c或.123）
用 Pattern.compile() 提升重复校验性能
如果校验逻辑出现在高频路径（如注册接口每秒调用数十次），每次都用 matches() 会重复编译正则，浪费 CPU。应将 Pattern 实例缓存为 static final。
注意点：
- 正则字符串里的反斜杠要双写，比如
"\."表示字面量点，不是通配符 - 不要在方法内反复
Pattern.compile(...)，哪怕加了final局部变量也无效 - 若需忽略大小写，用
Pattern.CASE_INSENSITIVE标志，而不是在正则里写[A-Za-z]
示例：
private static final Pattern EMAIL_PATTERN = Pattern.compile("^[A-Za-z0-9._%+-]+@[A-Za-z0-9.-]+\.[A-Za-z]{2,}$");
public static boolean isValidEmail(String email) {
return email != null && EMAIL_PATTERN.matcher(email).matches();
}
为什么不用 RFC 5322 全量校验？
RFC 5322 定义的邮箱格式极其复杂，例如 "John..Doe@example.com"（双点）、""quoted string"@example.com"、甚至带注释的格式都算合法。真实业务系统几乎从不接受这类邮箱 —— 邮箱服务商（Gmail、Outlook）本身就不支持，前端输入框也通常禁用双点或引号。
所以工程实践中的“校验”，本质是过滤掉明显无效输入，而非模拟 SMTP 协议层验证。真正可靠的验证方式只有发一封确认邮件并等待用户点击链接。
如果你硬要兼容 RFC 子集，别自己写正则，用现成库如 org.apache.commons.validator.routines.EmailValidator，但它仍默认关闭引号和注释支持，且内部也是基于简化正则。
容易被忽略的边界情况
即使用了较严谨的正则，以下情况仍常被遗漏：
-
null或空字符串：必须先判空，否则matches()抛NullPointerException - 首尾空白：用户可能粘贴带空格的邮箱，如
" test@example.com "，应先trim() - 中文邮箱（如
张三@公司.cn）：虽然 DNS 支持 IDN，但绝大多数 Java 邮件库、数据库字段、前端控件都不处理，建议统一拒绝 - 过长字符串：邮箱总长超 254 字符即违反 RFC，但正则不检查长度，需额外
email.length()
最终校验逻辑应类似：
public static boolean isValidEmail(String email) {
if (email == null || email.trim().isEmpty()) return false;
String trimmed = email.trim();
if (trimmed.length() > 254) return false;
return EMAIL_PATTERN.matcher(trimmed).matches();
}
真正的难点不在正则怎么写，而在于明确业务接受什么、拒绝什么。很多团队花半天调正则，却没共识“是否允许 + 号（Gmail 别名）”或“要不要查 MX 记录”，结果上线后才发现规则和运营策略打架。
