filter_var()是PHP验证邮箱、URL、整数等语义类型的标准入口，比正则更安全省心，自动处理空格与编码边界，但默认不trim需手动处理，且返回false而非空值。
验证邮箱、URL、整数时直接用 filter_var()
它不是“另一种方案”，而是 PHP 官方为常见语义类型设计的默认校验入口。比如 filter_var($email, FILTER_VALIDATE_EMAIL) 能识别 test@.com、user@@domain.com、user@domain..com 这类明显非法格式，而手写正则容易漏掉边界 case；filter_var($url, FILTER_VALIDATE_URL, FILTER_FLAG_PATH_REQUIRED) 还能控制是否强制要求路径段。更重要的是，它自动处理前后空格（但注意：默认不 trim，" test@example.com " 会失败，得先 trim()）。
常见错误是把 $_GET['id'] 直接转 (int) 或用 is_numeric() ——它们对 "123abc"、" 456 " 都返回真或静默截断，完全失去校验意义。改用 filter_var($input, FILTER_VALIDATE_INT) 才真正拒绝非法后缀。
-
filter_var()对FILTER_VALIDATE_INT支持options参数，比如限定范围：['options' => ['min_range' => 1, 'max_range' => 100]] - 验证域名必须用
FILTER_VALIDATE_DOMAIN（PHP 5.6+），别用FILTER_VALIDATE_URL替代，后者不校验 host 合法性 -
filter_var()返回false表示失败，不是空字符串或null，判空时别写成empty()
需要自定义规则或提取子串时才用 preg_match()
它不是“更灵活的验证工具”，而是文本模式匹配引擎。当你需要从字符串里抽字段（比如从 "Order#12345-2026" 提取编号）、做多条件组合（密码强度：至少 1 个大写 + 1 个数字 + 1 个特殊字符）、或匹配非标准格式（如中国手机号 /^1[3-9]\d{9}$/）时，preg_match() 才不可替代。
但要注意：它不处理编码、不自动 trim、不感知语义。比如验证邮箱写 preg_match('/^.+@.+\..+$/', $email)，看似能过 test@example.com，但也会放过 test@.com 和 a@b.c.d.e.f.g.h.i.j.k ——这已经超出正则该管的范围。
立即学习“PHP免费学习笔记（深入）”；
- 用
preg_match()做验证前，务必先trim()输入，否则前后空格会导致误判 - 捕获组结果存在
$matches[1]、$matches[2]，但$matches[0]是完整匹配，别错当成第一个子组 - 需要全局匹配用
preg_match_all()，单次匹配够用就别用它，性能差一截
泛域名匹配不能靠 preg_match() 字符串替换
很多人想用 str_replace('*', $host, '*.example.com') 判断 api.example.com 是否匹配 *.example.com，这是典型错误。这种逻辑会让 foo.bar.example.com 匹配成功（实际应拒绝），也会让 example.com 错误通过（缺少子域）。
正确做法是分段比对：先用 explode('.', $host) 拆目标 host，再拆去 * 后的模板（如 example.com），最后用 array_slice($hostParts, -count($templateParts)) === $templateParts 确认尾部一致，且总长度严格大于模板段数。
- 必须先用
filter_var($host, FILTER_VALIDATE_DOMAIN, FILTER_FLAG_HOSTNAME)校验原始 host 合法性，否则*.exa_mple.com这种含下划线的输入会绕过正则直接进匹配逻辑 -
$_SERVER['HTTP_HOST']可被客户端伪造，泛域名匹配结果不能用于权限控制或安全决策 - PHP 旧版本（FILTER_VALIDATE_DOMAIN，需降级用
idn_to_ascii()+ 正则兜底
性能和可维护性差异比想象中大
filter_var() 是 C 实现的内置函数，开销极低；preg_match() 每次调用都要编译正则（即使缓存了 pattern），在循环里高频使用会明显拖慢响应。线上接口若对每个请求都跑一遍密码强度正则，不如提前用 filter_var() 做基础长度/类型检查，再对疑似强口令走正则。
更关键的是可读性：filter_var($input, FILTER_VALIDATE_EMAIL) 一眼看懂意图；而 preg_match('/^[a-z0-9._%+-]+@[a-z0-9.-]+\.[a-z]{2,}$/i', $input) 即使写对了，半年后你自己都得盯两分钟才能确认有没有漏掉点号转义。
真正复杂的需求（比如解析带引号的邮箱地址 "John Doe" <john></john>）不该硬塞进一个正则，而应分层：先用 filter_var() 验证核心部分，再用 preg_match() 提取昵称段——各司其职。
