PHP filter_var 怎样校验 URL 与邮箱地址

在 PHP 表单里接收邮箱和链接时，最容易踩的坑不是函数不会用，而是把“默认过滤”“语法校验”和“业务允许”混成了一件事。用 filter_var() 时，邮箱应传入 FILTER_VALIDATE_EMAIL，URL 应传入 FILTER_VALIDATE_URL，并且用严格比较判断返回值。

官方地址：https://www.php.net/manual/en/function.filter-var.php

记住一句话：filter_var 只告诉你输入是否符合过滤器的规则；URL 是否允许访问、邮箱是否真的存在，还要由业务规则或后续确认流程决定。

filter_var 的返回值先看懂

filter_var($value, $filter, $options) 的第二个参数决定过滤器。若省略它，默认的 FILTER_DEFAULT 是 FILTER_UNSAFE_RAW 的别名，不会自动完成 URL 或邮箱校验。校验成功时通常返回过滤后的值；校验失败时返回 false。

因此，不要把所有结果都写成真假判断后直接继续处理。URL 和邮箱成功时返回字符串，失败时返回布尔值 false，下面这种严格比较最清楚：

邮箱地址用 FILTER_VALIDATE_EMAIL 校验什么

FILTER_VALIDATE_EMAIL 检查的是邮箱地址的语法形态。比如 dev@example.com 这类输入通常会返回原字符串，而缺少必要结构的输入会返回 false。它不会把原字符串改写成“清洗后”的另一个地址，因此不要用 FILTER_SANITIZE_EMAIL 的结果代替校验结果：清洗只是删除部分字符，并不等于地址有效。

PHP 手册说明，该验证基于 addr-spec 语法，但注释、折叠空白和无点域名不受支持；如果业务需要接受本地部分中的 Unicode 字符，可以按场景考虑 FILTER_FLAG_EMAIL_UNICODE。这仍然只是格式判断，不能证明邮箱有人使用，也不能证明邮件一定能投递，真正的确认通常要靠验证邮件或业务侧确认。

URL 校验后为什么还要检查协议

FILTER_VALIDATE_URL 适合先判断 URL 的基本语法，但它不是“只允许网页链接”的安全策略。官方文档特别提醒：除了 http:// 和 https:// 以外，其他 scheme 的主机内容可能被宽松接受，scheme 本身也不会按你的业务白名单验证；过滤器还只处理 ASCII URL，国际化域名可能被拒绝。

所以当字段含义是“用户主页”或“回调地址”时，先让过滤器判断格式，再用 parse_url() 取出 scheme，只允许业务认可的协议。需要路径或查询串时，再分别使用 FILTER_FLAG_PATH_REQUIRED 或 FILTER_FLAG_QUERY_REQUIRED；旧的 FILTER_FLAG_SCHEME_REQUIRED 和 FILTER_FLAG_HOST_REQUIRED 在 PHP 8 中已经不应继续依赖。

把语法通过、业务允许和真实存在分开

落地时可以按三层判断：第一层由 filter_var 判断语法；第二层检查协议、长度、是否允许内网地址等业务限制；第三层才是访问、发送验证邮件或等待回调等真实性确认。不要把第二层和第三层悄悄塞进过滤器的结论里。

还要注意输入来源。如果值来自已经取出的变量，使用 filter_var；如果直接读取原始请求变量，可以考虑 filter_input()。校验通过后仍应按输出场景进行 HTML 转义，URL 若会进入跳转或请求流程，也要单独设计允许列表和访问策略。

常见问题

为什么 filter_var 返回 false，却不能直接用 if 判断所有过滤器？

因为部分过滤器的有效结果本身可能是布尔值 false 或整数 0。URL 和邮箱返回字符串或 false 时，严格比较已经足够；换到整数、布尔值等过滤器时，要按照对应的失败返回语义判断。

FILTER_SANITIZE_EMAIL 能不能代替 FILTER_VALIDATE_EMAIL？

不能。sanitize 会尝试清理输入，结果可能已经不是用户原始内容；validate 只回答“是否符合规则”。需要保存原值时，保留原输入，再单独保存校验结果。

FILTER_VALIDATE_URL 能不能证明链接能打开？

不能。它只做 URL 语法层判断。DNS、网络、服务器响应、认证和业务权限都属于后续问题，不能由一次 filter_var 调用代替。

最终可以把实现压缩成一个判断顺序：先选对 FILTER_VALIDATE_*，再严格比较返回值；URL 追加协议白名单，邮箱追加真实性确认；最后根据具体输出和网络场景做安全处理。