filter_var($email, FILTER_VALIDATE_EMAIL) 是验证邮箱格式最可靠方式，仅做 RFC 5322 语法校验，速度快且轻量；需配合 !empty() 判空、数据库去重及验证码发送才能保障真实可用性。

PHP 用 filter_var() 验证邮箱格式最可靠

直接用 PHP 内置的 filter_var() 配合 FILTER_VALIDATE_EMAIL，是验证邮箱格式最轻量、最标准的方式。它不发请求、不查 DNS、不连 SMTP，只做语法校验，速度快且符合 RFC 5322 基础规则。

常见错误是拿正则硬写邮箱匹配（比如 /^[a-z0-9._%+-]+@[a-z0-9.-]+\.[a-z]{2,}$/i），看似灵活，实则漏判合法邮箱（如含引号或+号别名）、误杀边缘合法格式（如 "test@domain".com），还容易被绕过。

实操建议：

• filter_var($email, FILTER_VALIDATE_EMAIL) 返回 false 表示格式无效，其他值（包括空字符串）都需额外判断——空值要单独用 !empty($email) 拦住
• 该函数不检测域名是否存在，也不验证邮箱是否真实可用；若需更高保障，后续必须加「发送验证码」环节
• 注意：PHP 8.1+ 对某些极端格式（如连续点号）校验更严格，旧版可能放过，升级后可能出现兼容性差异

表单提交时前后端都要校验，但逻辑不能重复

前端用 HTML5 的 type="email" 和 required 属性能拦截明显错误（如无 @ 符号），但纯属体验优化，完全可被禁用 JS 或抓包绕过。后端 PHP 校验才是唯一可信防线。

关键点在于：前后端校验目标一致（格式合规），但手段和责任不同。前端快速反馈，后端兜底执行。

实操建议：

• 前端不要依赖 JS 正则做完整校验， 足够，避免自定义正则和后端不一致
• 后端收到 POST 数据后，立刻对 $_POST['email'] 执行 filter_var()，失败就返回 JSON 错误（如 {"error": "邮箱格式不正确"}），不继续执行注册逻辑
• 不要在数据库插入后再校验——出错时已产生脏数据或触发多余日志

用户注册场景下，必须叠加「邮箱去重」和「验证码验证」

仅格式校验通过 ≠ 邮箱可用。真实业务中，两个高频问题会暴露单一校验的脆弱性：一是同一邮箱重复注册，二是恶意填写他人邮箱（如 admin@gmail.com）。

所以格式校验只是第一步，后面必须跟两步：

• 查库确认 $email 是否已存在于 users.email 字段（注意用预处理语句防注入）
• 生成随机 6 位验证码，调用 PHPMailer 或 mail() 发送（推荐用 SMTP 方式，mail() 在多数 Linux 主机上默认被拒收）
• 把验证码和邮箱哈希（如 sha256($email . $timestamp)）存入临时表或 Redis，设置 10 分钟过期

跳过这一步，等于把账号接管权交到攻击者手上。

注意 filter_var() 的边界情况和替代方案

filter_var() 对某

些合法但罕见的邮箱格式支持有限，例如含 UTF-8 本地部分（如 张三@domain.com）或带注释的旧式格式（user /* comment */ @domain.com）。现代系统通常不需要兼容这些。

如果你明确需要国际化邮箱（IDN）支持，得先用 idn_to_ascii() 转换域名部分，再校验：

$email = '张三@例子.中国';
list($local, $domain) = explode('@', $email, 2);
$ascii_domain = idn_to_ascii($domain, 0, INTL_IDNA_VARIANT_UTS46);
$normalized = $local . '@' . $ascii_domain;
if (!filter_var($normalized, FILTER_VALIDATE_EMAIL)) {
    // 格式错误
}

不过绝大多数国内项目，用户邮箱仍是 ASCII 为主，强行支持 IDN 反而增加存储和兼容风险。真有需求，优先考虑前端限制输入法，而非后端硬扛。

复杂点往往不在校验本身，而在「什么时候校验」「校验后怎么流转」「失败后如何提示而不泄露信息」——比如邮箱是否已注册，应统一返回「邮箱不可用」，而不是区分「格式错误」或「已被占用」。