filter_var($email, filter_validate_email)是php验证邮箱格式最可靠的方式，它符合rfc标准、处理边界情况、无需正则且不依赖第三方库，但仅校验格式，不检查域名存在性或可收信性。
用 filter_var 做邮箱验证最靠谱
PHP 自带的 filter_var 是验证邮箱格式最省心、也最接近 RFC 标准的方式。它不依赖正则手写，也不需要引入第三方库，关键是——它能处理很多边界情况（比如带 + 号的 Gmail 地址、带引号的本地部分）。
常见错误是直接用 preg_match 写个简单正则，结果放过 user@ 这种明显缺域名的，或者拦住 test+newsletter@example.com 这种合法地址。
- 必须传
FILTER_VALIDATE_EMAIL作为第二个参数，漏掉就变成过滤（filter）而不是验证（validate） - 它只检查格式，不查域名是否存在、MX 记录有没有，别指望它替你发邮件测试
- 对国际化域名（IDN，比如含中文字符的域名）不支持，得先用
idn_to_ascii转换再验
示例：
if (filter_var($email, FILTER_VALIDATE_EMAIL)) {<br> echo "格式正确";<br>} else {<br> echo "格式错误";<br>}
为什么不用 preg_match 自己写正则
因为 RFC 5322 定义的邮箱格式极其复杂，完整正则长达上千字符，PHP 的 PCRE 引擎还可能栈溢出。网上流传的“一行正则”基本都只是近似匹配，要么太松（放过 a@b），要么太紧（拒绝 "John Doe"@example.com）。
立即学习“PHP免费学习笔记（深入）”；
真实场景里，你遇到的所谓“奇怪但合法”的邮箱，比如：user.name+tag@example.co.uk、"quoted"@example.org、user@[192.168.1.1]，filter_var 都能过，自己写的正则大概率挂掉。
- 别信“我这个正则已经测过 100 个样例”，RFC 允许的组合远超日常所见
- 如果真要正则（比如前端 JS 同步校验），用最简版
^[^\s@]+@[^\s@]+\.[^\s@]+$，但仅作快速拦截，后端仍须用filter_var - PHP 8.2+ 开始，
filter_var对某些极端 IDN 处理更稳，旧版本建议加mb_detect_encoding($email) === 'UTF-8'防乱码干扰
filter_var 验证失败的典型错误信息
它不会抛异常，只返回 false，所以不能靠捕获错误，得靠显式判断返回值。新手常犯的错是把 filter_var 当成布尔函数直接塞进 if，却忘了它对空字符串、null、数字也会返回 false，容易误判。
- 输入是空字符串
""→ 返回false，不是格式问题，是没输 - 输入是
null或0→ 同样返回false，需提前用is_string和trim做清洗 - 输入含不可见控制字符（比如粘贴时带的零宽空格）→ 返回
false，建议用trim($email, "\x00..\x1F\x7F")清理
稳妥写法：
$email = trim($email);<br>if (!is_string($email) || $email === '') {<br> return false;<br>}<br>return filter_var($email, FILTER_VALIDATE_EMAIL) !== false;
需要连通性验证？那就得另起炉灶
filter_var 只管格式，不查邮箱是否真实存在。如果你真要确认邮箱可收信（比如注册环节防小号），必须走 SMTP 检查或发送验证码。但注意：很多大厂邮箱（Gmail、Outlook）会静默丢弃验证请求，反而导致误判。
- SMTP
VRFY命令基本被禁用，别试 - 发信前做 DNS 查询（查 MX 记录）有一定参考价值，可用
checkdnsrr($domain, 'MX')，但gmail.com有 MX，fake@gmail.com也有，没用 - 真正可靠的方式只有发验证邮件并等用户点击链接，其他都是障眼法
格式验证和存在性验证是两层事，混在一起只会让代码又慢又不准。
事情说清了就结束。
