filter_var()最稳，覆盖邮箱、url等高频场景，需组合trim和严格比较判断失败，filter_input()一步取值验证更安全。
PHP里用filter_var()做基础验证最稳
别急着写正则或自定义函数，PHP内置的filter_var()覆盖了邮箱、URL、IP、整数、浮点数等高频场景，底层用C实现，既快又防绕过。它不依赖扩展，PHP 5.2+ 全默认支持。
常见错误是直接用filter_var($input, FILTER_VALIDATE_EMAIL)就完事——但这个函数对空字符串、纯空白、超长字符串（比如1000个a@b.c）不报错，实际业务中得组合判断：
-
trim($input) === ''先去首尾空格再判空 - 用
strlen($input) 卡住邮箱长度（RFC 5321上限） -
filter_var($input, FILTER_VALIDATE_EMAIL)只在非空且长度合规后才调用
注意：FILTER_SANITIZE_EMAIL会删掉所有非法字符，但不能替代验证——它把"test@domain..com"变成"test@domain.com"，看似“修好了”，实则掩盖了输入错误。
自定义规则必须用filter_var()的FILTER_CALLBACK
当需要“手机号必须11位且以1开头”“密码需含大小写字母和数字”这类逻辑，硬塞进filter_var()的内置类型不行，但强行写一堆if又难复用。正确姿势是用FILTER_CALLBACK封装校验函数：
立即学习“PHP免费学习笔记（深入）”；
filter_var($phone, FILTER_CALLBACK, ['options' => function($value) {
return preg_match('/^1[3-9]\d{9}$/', trim($value)) ? $value : false;
}]) !== false
关键点：
- 回调函数返回
false时，filter_var()整体返回false，和内置验证行为一致 - 不要在回调里抛异常——
filter_var()不捕获异常，直接崩 - 回调中必须
trim()，因为FILTER_CALLBACK不自动处理空白
性能上，比纯preg_match()略慢一丢丢，但换来的是统一入口、可组合、易测试。
验证失败时filter_var()返回false还是null？
这是最容易踩的坑：不同过滤器行为不一致。比如FILTER_VALIDATE_INT对"12.3"返回false，但FILTER_SANITIZE_NUMBER_INT对同样输入返回"123"（删掉小数点）。更隐蔽的是FILTER_VALIDATE_FLOAT对"1e5"返回100000.0，但对"1e500"这种溢出值返回false而非null。
所以判断失败只能用严格比较：
- 验证类过滤器（
FILTER_VALIDATE_*）：一律用=== false - 过滤类过滤器（
FILTER_SANITIZE_*）：结果可能是空字符串""，不是false，别用!$result判 - 永远别依赖返回
null——PHP文档没保证这点，实际版本间可能变
安全上，false意味着“无法确认合法”，必须拦截；而""是明确的空值，要按业务逻辑决定是否允许。
为什么不用$_POST直接验证？得先filter_input()
直接从$_POST['email']取值再验证，等于把原始输入暴露给整个流程。万一中间某步忘了trim()或误用了==松散比较，就埋下漏洞。正确做法是用filter_input()一步到位：
$email = filter_input(INPUT_POST, 'email', FILTER_VALIDATE_EMAIL, [
'options' => ['default' => null]
]);
它做了三件事：取值 + 过滤/验证 + 设默认值。好处是：
- 输入源明确（
INPUT_POST、INPUT_GET、INPUT_COOKIE），不会错拿$_GET覆盖$_POST - 未传参时返回
null（按default配置），不是""或"0"这种易混淆值 - 绕过
magic_quotes_gpc等过时机制干扰（虽然PHP 8已移除，但老项目仍存在）
复杂点在于：嵌套数组如$_POST['user']['email']无法用filter_input()直接取，得先用filter_var_array()或手动递归处理——这时候别偷懒，宁可多写两行，也别让原始$_POST裸奔进业务层。
