PHP正则表达式验证邮箱地址：完整代码示例-php教程-PHP中文网

推荐使用filter_var()验证邮箱格式，因其兼容rfc标准、性能高且持续更新；需先trim()和mb_strtolower()预处理，再结合checkdnsrr()检查mx记录以确保可投递。

php正则表达式验证邮箱地址：完整代码示例

PHP用`filter_var()`验证邮箱比正则更可靠

直接上结论：别自己写正则验邮箱，PHP内置的filter_var($email, FILTER_VALIDATE_EMAIL)已覆盖绝大多数合法邮箱格式，且随PHP版本持续更新RFC兼容性。手写正则要么太松（放过user@.com），要么太紧（拒绝"quoted"@domain.com或含Unicode的现代邮箱）。

常见错误是看到网上流传的“超长正则”就复制粘贴——那些表达式往往基于过时RFC 5321/5322子集，且未处理IDN（国际化域名）转换、SMTP响应模拟等真实场景。

实操建议：

优先用filter_var()做基础语法校验，它底层调用C实现，性能高、无正则回溯风险
若需额外控制（如禁止gmail类免费邮箱），在filter_var()通过后再用preg_match()做白名单/黑名单匹配
注意filter_var()不检查MX记录或邮箱是否真实存在，仅验证格式

必须手动加`trim()`和`mb_strtolower()`

用户输入常带首尾空格或大小写混用，而邮箱本地部分（@前）理论上区分大小写（虽多数服务商忽略），域名部分（@后）必须小写。直接对原始字符串调用filter_var()会失败或产生歧义。

示例错误写法：filter_var(" User@EXAMPLE.COM ", FILTER_VALIDATE_EMAIL) → 返回false（因含空格）

正确处理步骤：

用trim()清除首尾空白
用mb_strtolower()转为小写（strtolower()不支持UTF-8域名）
再传给filter_var()

简短代码示例：

PHP

编写健壮的PHP代码，规避类型转换陷阱、数组怪癖及常见安全漏洞。

下载

$email = " User@EXAMPLE.COM ";
$email = trim($email);
if (empty($email)) {
    // 空字符串直接拒绝
}
$email = mb_strtolower($email);
if (!filter_var($email, FILTER_VALIDATE_EMAIL)) {
    // 格式不合法
}

需要真正发邮件时，别只信`filter_var()`

通过filter_var()只代表“看起来像邮箱”，不代表能收信。比如test@localhost、user@invalid-tld都可能通过验证，但无法投递。

生产环境必须分两层验证：

第一层：用filter_var()筛掉明显非法格式（快速失败）
第二层：用checkdnsrr()查MX记录（如checkdnsrr($domain, 'MX')），确认域名可接收邮件
注意checkdnsrr()不支持IPv6-only环境，且某些CDN或防火墙会拦截DNS查询

获取域名部分需小心：$domain = substr($email, strpos($email, '@') + 1)，不能用explode('@', $email)[1]——当邮箱含多个@（如"a@b"@c.com）时会出错。

真要写正则，至少避开这三个坑

如果业务强制要求用正则（如前端JS同步校验），以下三点必须处理：

本地部分允许点号，但不能连续（user..name@example.com非法），也不能开头结尾（.user@example.com非法）
域名部分需支持多级子域和国际化域名（IDN），但PHP正则默认不解析Punycode，得先用idn_to_ascii()转换
整个邮箱长度上限254字符（RFC 5321），正则里硬编码{1,254}不如代码层判断

极简安全正则示例（仅作参考，仍推荐filter_var()）：

$pattern = '/^[a-zA-Z0-9.!#$%&\'*+\/=?^_`{|}~-]+@[a-zA-Z0-9](?:[a-zA-Z0-9-]{0,61}[a-zA-Z0-9])?(?:\.[a-zA-Z0-9](?:[a-zA-Z0-9-]{0,61}[a-zA-Z0-9])?)*\.[a-zA-Z]{2,}$/';
// 注意：此正则不支持引号包裹的本地部分、Unicode域名、+号别名等

IDN域名必须先转换：$ascii_domain = idn_to_ascii($domain, IDNA_DEFAULT, INTL_IDNA_VARIANT_UTS46)，否则正则匹配会失败。

复杂点在于，邮箱规范本身在演进，而正则是一次性快照。越想覆盖全面，越容易引入回溯灾难或误判。实际项目里，格式校验交给filter_var()，业务规则（如禁用临时邮箱）单独用str_ends_with()或in_array()处理，更清晰也更可持续。