应使用 filter_var($x, filter_validate_int, ['options' => ['min_range' => $min, 'max_range' => $max]]) 进行严格整型范围验证，它先确保输入为合法整数（拒绝字符串、浮点、非法格式），再检查是否在指定区间内，且正确处理溢出与边界。
PHP 判断整型是否在指定范围内，别用 is_int() 先验过滤
因为 is_int() 只管类型，不管值——字符串 "123" 是数字但不是 int，而 123.0 在 PHP 7+ 中可能被当成 float，is_int(123.0) 返回 false。真要验“是不是合法的整数且落在某区间”，得拆成两步：先转准、再比范围。
常见错误现象：
• 用 filter_var($x, FILTER_VALIDATE_INT) 但没设 options，结果 "123abc" 被截成 123 还算通过
• 直接 $x >= 1 && $x ，但 $x 是字符串 <code>"50 "（带空格）或 "0x32"（十六进制），比较时静默转成 0 或 50，逻辑失控
- 必须先用
filter_var($x, FILTER_VALIDATE_INT, ['options' => ['min_range' => $min, 'max_range' => $max]])—— 它同时做类型校验 + 范围检查，且拒绝非法格式（如带空格、前导零八进制、科学计数法） - 如果允许字符串输入但需严格解析，加
FILTER_FLAG_ALLOW_THOUSAND要谨慎：它会让"1,000"通过，但后续计算可能出错 - 注意 PHP 整型溢出：32 位系统上
PHP_INT_MAX是 2147483647，若传入"2147483648"，filter_var会返回false（不溢出转换），这是预期行为
用 filter_var 验证带范围的整数，参数不能漏 min_range 和 max_range
这两个选项必须成对出现才能启用范围检查；只写一个，另一个默认为 null，范围验证就失效。而且它们只对成功解析出的整数生效——也就是说，先确保是合法整数，再套范围。
使用场景：
• 表单接收分页参数 page=3，要求 ≥1 且 ≤1000
• API 接收用户等级 level="5"，只接受 1–99
立即学习“PHP免费学习笔记（深入）”；
-
filter_var("5", FILTER_VALIDATE_INT, ['options' => ['min_range' => 1, 'max_range' => 99]])→ 返回5（合法） -
filter_var("0", FILTER_VALIDATE_INT, ['options' => ['min_range' => 1, 'max_range' => 99]])→ 返回false（越下界） -
filter_var("abc", FILTER_VALIDATE_INT, ['options' => ['min_range' => 1, 'max_range' => 99]])→ 返回false（非整数） -
filter_var("100", FILTER_VALIDATE_INT, ['options' => ['min_range' => 1]])→ 返回100（没设max_range，不限上界）
为什么不用 ctype_digit() + intval() 手动判断？
因为 ctype_digit() 只认纯数字字符串（不含负号），所以 "-5" 直接挂掉；而 intval() 在遇到非数字字符时会截断，intval("123abc") 得到 123，再比范围就完全失真。
性能影响：
• filter_var 内部做了完整解析和边界检查，比手动组合快且安全，PHP 7.2+ 对它的优化已很成熟
• ctype_digit() 虽快，但只解决“正整数字符串”这一子集，补负号、去空格、防溢出全是额外代码，综合成本更高
- 别写
ctype_digit(ltrim($x, '-'))来支持负数——"--5"或"- 5"依然能绕过 - 别依赖
intval($x) === $x判断是否为整数——intval("1e2")是100，但"1e2" === 100永远 false，逻辑断裂 - 若必须兼容极老 PHP（/^-?\d+$/ +
strlen长度限制 + 手动范围比对，但维护成本陡增
边界值和类型松散比较的坑，PHP 默认不报错但结果反直觉
PHP 的 == 会触发类型转换，"100" == 100 是 true，但 "100 " == 100 也是 true（空格被忽略），而 "100.0" == 100 同样 true。这些“看似相等”在业务里往往不该通过。
容易踩的坑：
• 把 POST 数据直接丢进 if ($x >= 1 && $x ，结果 <code>$x = "50.5" 被转成 50，意外通过
• 用 in_array($x, range(1, 100))，但 range() 生成的是 int 数组，"50" 字符串查不到（in_array 默认松散比较，但 range 里没字符串）
- 永远用
filter_var做第一道关卡，它返回false或 int，不会留模糊中间态 - 如果后续还要用这个值计算，直接用返回的整数，别再
(int)$x二次转换——避免重复解析 - 调试时打印
gettype($x)和var_export($x)，比只看echo $x更早发现类型污染
最麻烦的其实是隐式转换链：字符串 → float → int → 比较。一旦某个环节没卡死类型，后面全不可信。所以验证这一步，宁可啰嗦，不能省。
