PHP整型变量本身不限制范围，靠手动校验
PHP的int类型由底层平台决定（通常是32或64位），语言层不提供“声明时限定取值区间”的语法。所谓“限制范围”，本质是运行时对输入值做条件判断和拦截——不是类型系统的事，是业务逻辑的事。
常见错误现象：filter_var($x, FILTER_VALIDATE_INT, ['options' => ['min_range' => 1, 'max_range' => 100]])返回false，但开发者误以为这是类型定义失败，其实它只是校验失败；还有人用cast强制转(int)掩盖溢出问题，结果9223372036854775808变成-9223372036854775808（64位有符号溢出）却毫无感知。
- 使用场景：表单提交、API参数解析、配置项加载后校验
- 不要依赖
(int)转换来“修复”越界值——它会静默截断或翻转 - 优先用
filter_var带范围选项，比手写if ($x 100)更安全（自动处理字符串数字、空格等边界）
filter_var + min_range/max_range 是最稳的校验方式
PHP内置的filter_var在数值校验上比手工比较更健壮，尤其处理字符串输入时能自动过滤空白、识别科学计数法，并拒绝非法格式（如"123abc"）。
参数差异关键点：'min_range'和'max_range'只在FILTER_VALIDATE_INT下生效，且要求输入必须是纯数字字符串或整数；若传入float（如3.14），即使落在区间内也会返回false。
立即学习“PHP免费学习笔记（深入）”；
-
filter_var("42", FILTER_VALIDATE_INT, ["options" => ["min_range"=>1, "max_range"=>100]])→42 -
filter_var(" 50 ", FILTER_VALIDATE_INT, ...)→50（自动trim） -
filter_var("101", FILTER_VALIDATE_INT, ...)→false -
filter_var(3.14, FILTER_VALIDATE_INT, ...)→false（不是整数）
注意 intval() 和 (int) 的陷阱：它们不校验，只转换
intval()和(int)都是强制类型转换，不是校验函数。它们会把任何值转成整数，过程中丢失精度、忽略范围、甚至产生意外结果。
典型坑：intval("123px")返回123（从左取数字直到非数字），(int)"99999999999999999999"在32位环境直接变2147483647（INT_MAX），64位也可能因超限回绕。
- 永远别用
(int)代替校验——它连"abc"都转成0 - 如果必须转换，先用
filter_var(... FILTER_VALIDATE_INT)确认合法性，再转 is_int($x) && $x >= 1 && $x 适用于已知是整数变量的快速检查，但无法处理字符串输入
超大整数或需要严格精度时，别用 int
当业务涉及金融、ID生成、时间戳差值等场景，PHP默认int可能不够用（比如MySQL的BIGINT UNSIGNED最大值远超PHP有符号64位整型上限）。这时硬塞进int会翻车。
性能与兼容性影响：启用bcmath或用string存大数虽安全，但所有计算都要换函数（bcmul、bcadd），不能直接用+或==；且JSON编码时string类型会被当成字符串而非数字。
- 判断是否需升级：看数据来源——来自数据库
BIGINT字段？来自外部API的19位ID？如果是，优先按string接收并用filter_var($s, FILTER_VALIDATE_INT)校验格式 - 避免用
settype($x, 'int')处理可能超界的字符串 - 配置项里写死的整数常量（如
MAX_RETRY = 5）放心用int，这种不会溢出
真正容易被忽略的是：校验必须发生在**数据进入业务逻辑前**，而不是在DAO层或模板里补救。一个没校验的$_GET['page']传进SQL offset，后面再怎么修都晚了。
