filter_var()搭配filter_validate_int是php中验证并转换整型最稳妥的方式，它严格识别纯数字（可带±），拒绝科学计数法、十六进制、空格及小数点，并支持范围限制；返回false表示失败，0是合法值。
用 filter_var() 验证并转换整型最稳妥
PHP 里清洗非法整型，不是靠 (int) 强转或 intval() 截取——它们会静默把 "123abc" 变成 123，把 "0x1A" 变成 0，看似“成功”，实则丢数据、埋漏洞。
filter_var() 是唯一能真正区分「合法整数字符串」和「含干扰字符的伪整数」的内置方案。
实操建议：
- 始终搭配
FILTER_VALIDATE_INT使用，它只认纯数字（可带+/-），拒绝科学计数法、十六进制、空格包裹、小数点等 - 需要范围限制时，用
options数组传min_range和max_range，比如防止 ID 越界或金额为负 - 注意：它返回
false表示验证失败，不是0；0是合法整数，别用== false判错
if (false === filter_var($input, FILTER_VALIDATE_INT, ['options' => ['min_range' => 1, 'max_range' => 9999]])) {
// 输入非法，不是整数或超出范围
}
为什么 is_numeric() 和 ctype_digit() 不适合整型清洗
这两个函数常被误用，但语义和安全目标完全错位。
立即学习“PHP免费学习笔记（深入）”；
is_numeric() 会把 "1e5"、"0xFF"、" 42 " 都判为 true——它检测的是「是否可被 PHP 解析为数字」，不是「是否是整型字符串」。
ctype_digit() 看似严格，但它要求字符串**非空且每个字符都是 0–9**，直接拒掉负数（"-123"）、带符号的正数（"+456"），实际场景中几乎不可用。
常见错误现象：
- 用户提交
"123px"，is_numeric()返回 true，后续强转成123，样式单位被吞，逻辑出偏 - API 接收
"-5"，用ctype_digit()判为 false，直接拒绝合法负整数 - 前端传来
" 789 "（带空格），ctype_digit()失败，is_numeric()成功但掩盖了格式污染
从表单/URL 获取整型参数时的典型处理链
真实请求里，整型参数往往混着空格、换行、编码字符，甚至攻击载荷（如 "123<script>"</script>）。不能只做一次过滤。
推荐组合动作：
- 先用
trim()去首尾空白，避免" 123 "这类被filter_var()拒绝（它不自动 trim） - 再用
filter_var(..., FILTER_VALIDATE_INT)验证，失败就终止流程 - 如果业务允许默认值（比如分页
page=缺失时设为 1），在验证失败后显式赋默认，而不是 fallback 到intval() - 绝不把未验证的原始输入拼进 SQL、shell 命令或 HTML 输出——哪怕你刚用
filter_var()验过
$page = trim($_GET['page'] ?? '');
if (false === $page_int = filter_var($page, FILTER_VALIDATE_INT, ['options' => ['min_range' => 1]])) {
http_response_code(400);
exit('Invalid page number');
}
注意 filter_var() 的兼容性与隐式行为
PHP 5.2+ 全支持，但有两个容易忽略的细节：
- 当输入是
null、""或纯空白字符串时，filter_var(..., FILTER_VALIDATE_INT)返回false，不是0。这点和intval()完全不同 - 它不会自动处理 UTF-8 BOM 或零宽空格（
\u200b），这类字符会让验证失败。如果必须支持，得前置用preg_replace('/[\x{200B}-\x{200D}\x{FEFF}]/u', '', $input)清理 - 性能上毫无压力，比手写正则快且安全；但别用它替代数据库层的类型约束或 ORM 的字段校验——它是第一道入口过滤，不是最终防线
真正麻烦的从来不是怎么写对一行过滤代码，而是忘记检查上游是否已做过截断、是否留有不可见字符、是否在多个地方重复清洗又漏掉一处。安全清洗的本质，是让非法输入在最早可能的节点就彻底无法进入业务逻辑。
