推荐使用 /^[^\s@]+@[^\s@]+.[^\s@]+$/ 验证邮箱，它简洁安全、兼容常见变体如 user+tag@gmail.com，避免 rfc 5322 正则导致的回溯超限；filter_var() 可初筛但校验过松，建议叠加点约束；unicode 邮箱需启用 u 修饰符并谨慎使用。
PHP 用 preg_match() 做邮箱匹配，别直接抄网上那些“完美正则”，99% 的场景用 /^[^\s@]+@[^\s@]+\.[^\s@]+$/ 就够了，既安全又不会误杀合法邮箱（比如带 + 号的 Gmail）。
为什么不用 RFC 5322 官方正则？
官方邮箱规范太复杂，正则长度超 600 字符，PHP 的 preg_match() 在 PCRE 回溯限制下容易触发 PREG_BACKTRACK_LIMIT_ERROR，而且实际业务中根本不需要匹配“Abc\@def@example.com”这种边缘写法。
常见错误现象：preg_match() 返回 false 却没检查 preg_last_error()，误以为“没匹配到”，其实是回溯超限。
- 真实邮箱地址基本都满足「本地部分@域名.后缀」结构，中间不带空格和控制字符
- 用
[^\s@]+比[a-zA-Z0-9._%+-]+更宽泛也更安全——它允许未来新增的合法字符，且避免漏掉像user+tag@gmail.com这种常见变体 - 域名部分必须含至少一个点（
\.），否则会把user@localhost这类非法地址放行
filter_var($email, FILTER_VALIDATE_EMAIL) 足够吗？
够，但要注意它的验证逻辑比基础正则还松：它接受 user@domain（无点）、user@123.456.789.012（IP 形式），甚至 user@[123.456.789.012]（带方括号的 IPv4）——这些在 Web 表单里几乎不会出现，反而可能被滥用于绕过前端校验。
使用场景：filter_var() 适合快速初筛或日志清洗；但做注册/登录入口校验时，建议叠加一层带点约束的正则，防止明显错字（如 name@@gmail.com）漏过。
-
filter_var()不校验 DNS 或 MX 记录，纯语法检查 - 它对 Unicode 域名（如
用户@例子.中国）支持有限，PHP 7.4+ 才逐步改善 - 如果项目已用
filter_var()，可加个简单正则补丁：if (filter_var($email, FILTER_VALIDATE_EMAIL) && preg_match('/@.*\./', $email)) { ... }
带 Unicode 支持的邮箱正则怎么写？
需要匹配中文域名或用户名（如 张三@公司.中国），就得启用 UTF-8 模式，并替换 ASCII 字符类。但注意：不是所有邮箱服务商支持，且 PHP 的 PCRE 必须编译时开启 UTF-8 支持（默认通常开启）。
实操建议：只在明确需要国际化邮箱的场景才启用，否则增加复杂度且无收益。
- 启用
u修饰符：/^[^\s@]+@[^\s@]+\.[^\s@]+$/u - 域名部分不能简单用
[^\s@]+，需允许 IDN（国际化域名）的 Punycode 编码形式（如xn--fsq.xn--0zwm56d），此时建议先用idn_to_ascii()转换再走基础正则 - 别试图用正则解析邮箱的「本地部分」细节（如引号包裹、转义字符），SMTP 层才管这个，应用层只需确保结构合理
真正容易被忽略的是：邮箱校验只是第一道关卡，后续必须配合验证码、邮箱激活链接、以及 SMTP 发信结果反馈来确认真实性。正则再准，也拦不住填错邮箱的用户——或者故意填别人邮箱的攻击者。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
