filter_var($email, filter_validate_email) 仅校验 rfc 5322 语法合规性，不验证域名真实性或可投递性，故会放行 test@.com、user@domain. 等边缘合法格式；需配合 trim()、类型检查、url 解码及轻量正则二次过滤。
为什么 filter_var($email, FILTER_VALIDATE_EMAIL) 有时会放行明显错误的邮箱
它只校验语法合规性，不验证邮箱是否真实存在或域名是否可投递。比如 test@.com、user@domain.、admin@localhost 都可能通过——因为 RFC 5322 允许某些边缘写法，而 PHP 的实现偏向宽松兼容。
常见错误现象：filter_var('a@b', FILTER_VALIDATE_EMAIL) 返回 true（b 不是合法域名，但被当成本地域接受）；'user@domain..com' 却返回 false（双点直接拒绝）。
- 真正要拦截的：空字符串、无 @ 符号、@ 后无点号（如
u@x）、连续点号、开头或结尾是点号 - 可接受但需警惕的：
user+tag@example.com（带标签）、"quoted"@example.org（引号包裹）——这些是合法的，别误杀 - 若业务要求严格（如注册环节），建议在
filter_var基础上追加正则二次过滤，例如检查域名部分是否含至少一个点且不以点开头/结尾
用 filter_var 校验前必须做的三件事
不是丢个变量进去就完事。漏掉任意一步，都可能导致绕过或误判。
- 先
trim()：用户粘贴时容易带首尾空格，filter_var(" test@example.com ", FILTER_VALIDATE_EMAIL)会返回false - 确保输入是字符串：传入
null、array或数字会静默失败，返回false或原值（取决于 PHP 版本），务必先is_string()判断 - 避免编码污染：URL 中传来的邮箱可能被两次 URL 编码，
%40没解码就校验必然失败，调用前先urldecode()或rawurldecode()
filter_var 和正则校验混用时的性能与风险平衡
纯正则（如 /^.+@.+\..+$/）快但不准；filter_var 准但无法控制粒度。两者结合才是常见生产方案。
- 推荐顺序：先
trim→ 再filter_var基础校验 → 最后用轻量正则检查域名结构（如/^[a-zA-Z0-9.-]+\.[a-zA-Z]{2,}$/匹配@后部分） - 别用 PCRE 的
preg_match('/^[a-z0-9._%+-]+@[a-z0-9.-]+\.[a-z]{2,}$/i')替代filter_var：它漏掉引号邮箱、IDN 域名，且大小写处理不一致 - 注意
filter_var在 PHP 8.1+ 对 IDN（国际化域名）支持更好，但若需转 Punycode，得额外调用idn_to_ascii()，否则用户@中文.com会直接失败
测试时最容易忽略的边界邮箱案例
光测 test@example.com 没用。真实环境中出问题的，往往卡在这些点上。
-
" "@example.org（引号内全空格）：filter_var认为合法，但 SMTP 拒绝 -
user@exam\@ple.com（域名中含未转义 @）：语法非法，但某些旧版 PHP 可能不报错 -
user@[192.168.1.1]（IP 形式域名）：RFC 允许，filter_var通过，但多数邮箱服务不接受 -
user@sub.domain.co.uk：正确；但user@domain.co（无顶级域）会被filter_var放行，实际不可用
复杂点在于：校验永远只能到“格式大概率可用”这层。真要确认邮箱有效，最终还得靠发送验证邮件并等待点击链接——所有前端和 PHP 层的检查，只是第一道筛子。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
