filter_var() 是最稳妥的邮箱格式验证方式，它基于 RFC 5322 覆盖多数合法变体，比手写正则更可靠、高效且兼容性好；但仅校验语法，不检查域名存在性或邮箱真实性，需配合邮件验证流程。
PHP filter_var() 是最稳妥的验证方式
用正则自己写邮箱校验，大概率会漏掉合法邮箱或误杀边缘情况。PHP 内置的 filter_var() 已覆盖 RFC 5322 大部分合理变体，且随 PHP 版本持续更新，比手写正则更可靠。
常见错误现象：用类似 /^[a-z0-9._%+-]+@[a-z0-9.-]+\.[a-z]{2,}$/i 这种“看起来很全”的正则，结果把 "test+tag@domain.co.uk" 或带引号的 "john..doe@example.com"（虽不推荐但合法）直接判为无效。
- 使用场景：用户注册、表单提交、API 入参校验等需快速判断邮箱格式是否基本合规的场合
-
filter_var($email, FILTER_VALIDATE_EMAIL)返回false表示格式非法，否则返回原字符串（注意不是布尔true） - 它不检查域名是否存在、MX 记录是否有效——那是后续 SMTP 验证的事，别混在一起做
- PHP 8.1+ 对国际化域名（IDN）支持更好，但若需兼容旧版本，先用
idn_to_ascii()转换再校验
为什么不用 preg_match() 写自定义正则
除非你明确知道要限制子集（比如只允许 ASCII 字母数字 + 常见符号），否则没必要碰正则。RFC 5322 定义的邮箱格式极其复杂，连空格、括号、注释都算合法（虽然实际中几乎没人用）。手写正则要么太松（放过明显错误），要么太紧（拒绝真实用户）。
典型翻车点："customer/department=shipping@example.com" 是合法邮箱，但 99% 的自定义正则会炸；"test@localhost" 在开发环境常见，filter_var() 接受它，而多数正则要求必须含点号和 TLD。
立即学习“PHP免费学习笔记（深入）”；
- 性能影响极小——
filter_var()是 C 实现，比 PHP 层正则快且稳定 - 兼容性无坑：PHP 5.2+ 全支持，无需额外扩展
- 如果真要加业务约束（如禁止 Gmail、只允企业域名），应该在
filter_var()通过后再用strpos()或str_ends_with()单独判断，而不是塞进正则里
验证通过 ≠ 邮箱真实存在
filter_var() 只管语法，不发任何网络请求。用户填 "nobody@nonexistent.tld" 也能过，只要格式对。
真正确认邮箱可收信，必须走双重验证流程：发含唯一 token 的邮件 + 用户点击链接或输入验证码。跳过这步直接“验证成功”，等于没验证。
- SMTP 连接测试（如
fsockopen()查 MX）不可靠：很多域名故意屏蔽探测，且无法判断邮箱前缀是否存在（user@domain.com的user可能根本不存在） - 某些 SaaS 验证 API（如 Hunter、NeverBounce）也只是概率估算，非 100% 准确
- 生产环境里，最务实的做法是：格式校验（
filter_var()）→ 发验证邮件 → 用户操作后才算激活
中文邮箱（IDN）需要额外处理
像 "张三@例子.中国" 这类含中文字符的邮箱，在 PHP 中直接传给 filter_var() 会失败，因为底层校验基于 ASCII。必须先转成 Punycode。
错误现象：filter_var("张三@例子.中国", FILTER_VALIDATE_EMAIL) 返回 false，但该邮箱本身是合法的。
- 正确做法：用
idn_to_ascii("例子.中国", IDNA_DEFAULT, INTL_IDNA_VARIANT_UTS46)得到"xn--fsq.xn--fiqs8s"，再拼回"张三@xn--fsq.xn--fiqs8s"去校验 - 注意：PHP 7.2+ 才默认启用
INTL_IDNA_VARIANT_UTS46，低版本要用IDNA_NONTRANSITIONAL_TO_ASCII - 用户名部分（@前）目前主流邮箱服务基本不支持中文，建议前端就禁用，避免后端复杂化
