is_int() 仅当变量类型为 int 时返回 true，不进行类型转换或字符串解析；filter_var($x, filter_validate_int) 才适合校验值是否可安全作整数用，支持范围限制与自动 trim。
is_int() 只认真正的 int 类型，不转类型也不做字符串解析
is_int() 的行为非常严格：它只对变量本身类型是 int 的返回 true，哪怕值是 42，只要它是 string 或 float，就直接判否。很多人用它来“判断用户输入是不是整数”，结果发现 is_int("123") 是 false，is_int(42.0) 也是 false —— 因为 PHP 中 42.0 是 float，不是 int。
常见错误现象：
- 表单提交的数字（如 $_GET['id']）永远过不了 is_int()，因为 HTTP 参数全是字符串
- 从 JSON 解析来的 42 在某些 PHP 版本中可能是 float（尤其带小数点但值为整数时）
- is_int(round(42.6)) 看似合理，但 round() 返回类型取决于 PHP 版本和参数，在 PHP 8.2+ 默认返回 int，老版本可能仍返回 float
- 如果目标是「值是否可安全当作整数用」，别只靠
is_int()，得结合filter_var($x, FILTER_VALIDATE_INT)或类型转换后比对 - 若必须用
is_int()，确保上游数据已明确 cast 过，比如$id = (int)$_GET['id']; is_int($id)才有意义 - 注意
is_int(null)、is_int(false)、is_int("")全是false，但它不报错，容易误以为“没匹配上=不是整数”，而实际是“根本不是数”
filter_var(..., FILTER_VALIDATE_INT) 是更实用的整数校验方式
比起 is_int()，filter_var() 做的是语义校验：它接受字符串、数字，检查其值是否落在整数范围内，并可选限制范围。它不关心底层类型，只关心“这个值能不能无损表示为整数”。
使用场景：
- 验证 URL 参数、表单字段、API 请求体中的数字字段
- 需要同时判断合法性 + 范围控制（比如 ID 必须在 1~999999）
- 和 is_numeric() 的区别在于：后者会放行 "1e3"、"0xFF" 等非十进制表达式，而 FILTER_VALIDATE_INT 默认只认十进制整数（除非显式加 FILTER_FLAG_ALLOW_HEX）
-
filter_var("123", FILTER_VALIDATE_INT)→ 返回123（int） -
filter_var("123.5", FILTER_VALIDATE_INT)→ 返回false -
filter_var(" -42 ", FILTER_VALIDATE_INT)→ 返回-42（自动 trim） - 加范围：
filter_var("500", FILTER_VALIDATE_INT, ["options" => ["min_range" => 1, "max_range" => 100]])→false
intval() 和 (int) 强转后，再用 === 比对能绕过类型陷阱
当你要“把某值当作整数用”，而不是“检查它本来是不是 int 类型”，最稳妥的做法是先转成 int，再确认转换没失真。比如 "123" → (int)"123" 是 123，且 "123" == (int)"123" 成立；但 "123abc" → (int)"123abc" 是 123，而 "123abc" != 123，说明原始值不纯。
性能 / 兼容性影响：
- (int) 和 intval() 性能几乎无差别，但 intval() 支持进制参数（如 intval("1010", 2)），(int) 不支持
- PHP 8+ 对字符串转 int 更严格（如空格开头会截断，但全空字符串转为 0），所以比对逻辑必须覆盖边界情况
- 推荐写法：
$val = "123"; $as_int = (int)$val; if ((string)$as_int === (string)$val) { /* 安全 */ } - 更简洁等价写法（利用 loose 比较特性）：
if ($val == $as_int && is_string($val) ? ctype_digit(ltrim($val, '-')) || ($val[0] === '-' && ctype_digit(substr($val, 1))) : true) { ... }—— 但太绕，一般用filter_var更稳 - 注意：
(int)"0x1A"得到0（不是 26），因为(int)不解析十六进制；filter_var("0x1A", FILTER_VALIDATE_INT, FILTER_FLAG_ALLOW_HEX)才能正确识别
JSON 解析后 is_int() 失效？那是因为 json_decode 默认返回 float
PHP json_decode() 在不传第二个参数 true 时，会把 JSON 数字统一转成 float，即使源 JSON 写的是 123。所以 is_int(json_decode('{"id":123}')->id) 必然是 false —— 这不是 bug，是设计如此。
立即学习“PHP免费学习笔记（深入）”；
容易踩的坑：
- 直接拿 json_decode($json)->id 去做数据库插入或类型敏感操作，结果因 float 导致精度丢失（尤其大整数，如微博/微信的 64 位 ID）
- 用 is_int() 判断失败后，误以为“数据格式错了”，其实只是类型映射规则不同
- 解决方案一（推荐）：
json_decode($json, true)得到关联数组，再用filter_var($arr['id'], FILTER_VALIDATE_INT) - 解决方案二（需精确控制）：
json_decode($json, false, 512, JSON_BIGINT_AS_STRING)，让大整数保持为字符串，再手动验证 - 不要依赖
is_int((int)$json_num)来“修复”，因为(int)截断 float 可能出错（如(int)9223372036854775807.0在 32 位系统上溢出）
实际项目里，真正需要 is_int() 的地方极少。多数时候你想要的不是“它是不是 int 类型”，而是“它能不能当整数用、有没有被篡改、是否在有效范围内”。这几个判断维度混在一起，光靠一个函数搞不定。类型校验只是起点，后面总得跟上范围检查、上下文适配和错误反馈。
