必须先过滤再转换，因intval()和(int)对非法字符串过于宽容，如"123abc"返回123、"0x1A"解析为26，易导致SQL注入或逻辑漏洞；正确做法是用filter_var($val, FILTER_VALIDATE_INT)校验后再转换。
PHP 表单输入转整型，不能直接 intval() 或强制类型转换完事——必须先过滤，再转换，否则可能绕过校验、引发 SQL 注入或逻辑漏洞。
为什么不能直接 (int) 或 intval()？
因为 intval() 和强制转换对非法字符串“太宽容”：比如 intval("123abc") 返回 123，(int)"123px" 也是 123；更危险的是 intval("0x1A") 解析为十进制 26，而 "1e3" 会被转成 1（科学计数法截断）。这些都不是用户真实意图，却能通过看似“整数”的校验。
常见错误现象：
-
表单提交
id=123%00abc（含空字节）→intval()仍得123，但后续pdo->prepare()绑定时若未严格类型化，可能被用于宽字节注入 -
前端隐藏字段写
→ 后端只用(int)$_POST['status']，结果是1，看似安全，实则掩盖了参数被篡改的事实
正确流程：先 filter_var() 过滤，再确认是否有效
用 filter_var() 的 FILTER_VALIDATE_INT 是最稳妥的起点，它只接受纯整数字符串（可带正负号），拒绝任何后缀、空格、符号混杂。
立即学习“PHP免费学习笔记（深入）”；
实操建议：
- 始终指定
options参数，例如限制范围：filter_var($_POST['age'], FILTER_VALIDATE_INT, ['options' => ['min_range' => 0, 'max_range' => 120]]) - 检查返回值是否为
false（验证失败）或null（输入为空或非字符串），不要只用if ($val)判定——因为0是合法整数，但会触发 falsey - 若需默认值，显式赋值：
$id = filter_var($_POST['id'], FILTER_VALIDATE_INT) ?: 0;，但注意这会把无效输入也转成0，业务上是否允许需单独判断
什么时候该用 ctype_digit()？
当且仅当你**明确只要非负十进制数字字符串**（如 ID、手机号前段、页码），且不接受负号、空格、+ 号时，ctype_digit() 比 filter_var(..., FILTER_VALIDATE_INT) 更严格、更快。
注意点：
-
ctype_digit()要求输入是字符串，且每个字符都是0-9；ctype_digit("-123")→false，ctype_digit(" 123")→false（含空格） - 它不处理类型转换，只是校验，之后仍需
(int)或intval()转换，但此时已知输入绝对安全 - 对空字符串、
null、数字类型变量会直接返回false，务必先is_string()判断
别忽略编码和空字节问题
如果表单数据来自不可信来源（如第三方回调、URL 参数拼接、文件上传字段名），原始字符串可能含 UTF-8 BOM、零宽空格、U+FFFD 替换符，甚至 \0。这些字符在 filter_var() 中会被当作非法字符拦截，但若跳过过滤直接转换，就可能出问题。
关键动作：
- 接收后立刻用
trim()去首尾空白（包括 Unicode 空格） - 对关键字段（如 ID、limit、offset）做
str_replace("\0", "", $input)防御空字节截断（虽然现代 PHP 已缓解，但旧环境或扩展仍可能受影响） - 确保整个请求使用统一字符集（推荐 UTF-8），并在
php.ini设置default_charset = "UTF-8"，避免mb_detect_encoding()误判导致过滤失效
真正麻烦的不是“怎么转成整数”，而是“怎么确认这个输入本意就是整数”。过滤不是多此一举，是把模糊的字符串语义，收束到确定的数值边界里——漏掉任意一环，后面所有类型假设都可能崩塌。
