filter_var($email, filter_validate_email) 是 php 唯一靠谱、轻量、符合 rfc 的邮箱格式校验方式，它调用底层 c 解析，但需 trim、判空、严格比较 false，且不处理 idn 和 dns 验证。
直接用 filter_var($email, FILTER_VALIDATE_EMAIL)，别写正则，也别查 DNS —— 它是 PHP 唯一靠谱、轻量、符合 RFC 的邮箱格式校验方式。
为什么不能直接用 preg_match 写正则？
手写正则看似自由，实则极易漏判或误拦：
- 放过
user@这种缺域名的明显错误 - 拦住
test+newsletter@example.com或"john..doe"@example.com这类合法地址 - 不支持引号包裹的用户名（如
"test email"@domain.com） - 对国际化域名（IDN，如
用户@例子.中国）完全无感，而现代邮箱已广泛使用 - 完整 RFC 5322 正则长达上千字符，PHP PCRE 可能栈溢出，且维护成本极高
filter_var 的正确用法和常见踩坑点
它不是“有没有 @ 和点”的简单判断，而是调用底层 C 实现的语法解析。但必须注意几个关键细节：
- 必须显式传
FILTER_VALIDATE_EMAIL，漏掉就变成FILTER_SANITIZE_EMAIL—— 后者是清理，不是校验 - 输入前务必
trim($email)，否则" user@example.com "会返回false - 要先确认类型：
!is_string($email) || $email === ''得单独判，因为filter_var('', FILTER_VALIDATE_EMAIL)返回''（非false），但空字符串显然非法 - 返回值判断要严谨：用
=== false，而不是== false或直接if (!filter_var(...))—— 因为合法邮箱可能返回字符串"0@example.com"，会被弱类型判断误认为false
什么时候需要额外加 DNS 或 IDN 处理？
filter_var 只管格式，不管语义。遇到以下场景才需扩展：
- 用户输入含中文/日文域名（如
test@你好.cn）：必须先用idn_to_ascii($email)转成 Punycode（test@xn--6qqa088e.cn），再喂给filter_var - 想粗略判断域名是否可能收信：提取
$domain后调用checkdnsrr($domain, 'MX')，但注意该函数在 Windows 上不可靠，且无法替代发验证码 - 业务强制要求子集格式（如禁用
+号或引号）：那是业务规则，不是格式校验，应在filter_var通过后再单独检查
真正容易被忽略的是：格式校验只是第一道门，后面必须跟数据库去重 + 验证码发送。否则，哪怕 filter_var 返回 true，也不能说明这个邮箱真实存在、能收到邮件、属于当前用户。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
