应分层验证邮箱：前端宽松校验，后端用filter_var($email, filter_validate_email)基础检查，最终靠发送验证邮件确认；preg_match仅作反向过滤且须加iu修饰符。
preg_match 匹配邮箱时为什么总漏掉合法地址
因为绝大多数人直接抄网上“最短正则”/^[a-z0-9._%+-]+@[a-z0-9.-]+\.[a-z]{2,}$/i，它看似能用，但实际会拒绝 test+tag@example.com（带加号的 Gmail 地址）、"quoted"@example.org（带引号的本地部分），甚至 user@sub.domain.co.uk（多级域名）。RFC 5322 定义的邮箱格式极其复杂，正则根本没法 100% 覆盖。
真实项目里，你应该分两层处理：
- 前端用宽松校验快速拦截明显错误（比如没
@、没点号） - 后端用
filter_var($email, FILTER_VALIDATE_EMAIL)做基础合规检查——它比手写正则更贴近 RFC，且 PHP 内置、无兼容性问题 - 真正要确认邮箱可用？只能发验证邮件，别信任何正则或过滤器
preg_match 中的 $pattern 写错一个修饰符就全失效
常见错误是忘记加 i 修饰符，导致 A@B.COM 被判无效；或者误加 m（多行模式），让 ^ 和 $ 在换行符处也匹配，破坏邮箱边界判断。
正确写法必须包含：
-
i：忽略大小写（邮箱域名不区分大小写） -
u：支持 UTF-8 字符（如中文邮箱张三@例子.中国，虽少见但合法） - 不要用
m、s、x等无关修饰符
示例：preg_match('/^[a-z0-9._%+-]+@[a-z0-9.-]+\.[a-z]{2,}$/iu', $email)
为什么用 filter_var 比死磕 preg_match 更靠谱
filter_var 是 PHP 官方维护的邮箱验证逻辑，内部做了 DNS 格式预检、长度限制（如本地部分 ≤64 字节）、禁止空格和控制字符等，而手写正则几乎没人完整实现这些。
性能上差异极小，但可靠性高得多。唯一要注意的是：
- 它不检查域名是否存在（
xxx@nonexistent.tld也会返回 true） - PHP 5.2.11+ 才完全支持 IDN（国际化域名），老版本遇到中文域名可能失败
- 如果必须用正则（比如 Nginx 的 rewrite 规则），就只做“反向过滤”：用正则剔除明显非法字符，再交给
filter_var
生产环境里最容易被忽略的两个点
一是用户输入前后常带空格或不可见字符（比如粘贴来的邮箱含 \r\n），不 trim 直接进 preg_match 或 filter_var 就会失败；二是某些邮箱服务允许注释，如 user@example.com (John)，虽然 RFC 允许，但 filter_var 会拒绝——这种边缘情况，要么提前 str_replace 掉括号及内容，要么接受它不通过校验。
真正上线前，务必拿这组测试数据过一遍："test@test.co.uk"、"a+b@c.d.e"、" user@domain.com "、"test@localhost"（后者在开发环境常见，但生产通常该禁）
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
