PHP中$_GET参数默认为字符串，直接使用易引发类型错误、SQL注入或警告；应先用filter_var校验并转换，再处理键存在性与默认值。
PHP中
参数默认是字符串，直接用会出问题
PHP的
数组里所有值都是字符串类型，哪怕URL里写的是
，
也是
（带引号的字符串）。直接拿它去查数据库、做数学运算或类型敏感判断（比如
），八成会踩坑。
常见错误现象：
–
永远不进分支
– MySQL查询
触发隐式类型转换，可能被绕过注入检测
– 传入
等函数时抛
（因为把字符串当数组用了）
永远别信
的类型，显式转换是底线
用
强制转换最常用，但要注意截断行为：比如
得
，
得
如果要严格校验“纯数字”，优先用
，它对
或
都返回
用
校验并转换整型更安全
不是简单转类型，而是带语义的验证——它能区分“这是个合法整数”和“这看起来像整数但混了别的东西”。尤其适合处理用户输入的ID、分页页码、状态码这类必须精确的场景。
使用场景：
– 接口要求
且不允许负数或超大值
– 管理后台URL里
必须确保是正整数
– 防止
被恶意用于SQL注入（配合后续白名单）
立即学习
“
PHP免费学习笔记（深入）
”；
PHP 8.5.5
PHP 8.5.5 是 PHP 8.5 分支的维护更新版本。该版本延续了“小步快跑”的迭代逻辑，通过深度错误修复、底层性能微调以及安全加固，旨在为开发者提供一个更健壮、更高效的运行环境。该版本严格遵守语义化版本规范，不包含破坏性变更。
下载
：只验证，合法返回int，非法返回
：加范围限制，超出即
注意
对空字符串
、
、未定义键都返回
，别忘了判空
和
的区别与陷阱
三者都能“转整数”，但行为差异明显：
和
是强制转换，
是验证后转换。选错就等于主动放行脏数据。
→
；
→
；
→
（容易把空参当0处理）
→
；
→
；但
也返回
，和
一样不可靠
支持进制转换，
不支持；但日常处理URL参数几乎用不到这个特性
性能上三者差距可忽略，别为这点速度牺牲安全性
别漏掉键存在性检查和默认值处理
很多新手只盯着“怎么转整型”，却忘了
可能根本不存在——这时
会触发
，而
会警告
。
先用
或
兜底
更简洁写法：
（
防未定义，
设默认值）
如果业务允许缺失参数（比如搜索页
没带
），默认值必须明确，别依赖
这种隐式逻辑
真正麻烦的从来不是“怎么转”，而是“转之前有没有确认它存在、是否在合理范围内、缺了怎么办”。这些边界情况一漏，线上就容易出500或查到不该查的数据。
$_GET$_GET?id=123$_GET['id']"123"=== 123if ($_GET['page'] === 1) { ... }WHERE id = $_GET['id']array_shift()Warning: array_shift() expects parameter 1 to be array$_GET(int)(int)"123abc"123(int)"abc123"0filter_var($val, FILTER_VALIDATE_INT)"123abc"" 123 "falsefilter_varfilter_var?limit=20?user_id=5000?sort=-1filter_var($_GET['id'], FILTER_VALIDATE_INT)falsefilter_var($_GET['page'], FILTER_VALIDATE_INT, ['options' => ['min_range' => 1, 'max_range' => 1000]])falsefilter_var""nullfalseintval()(int)(int)intval()filter_var(int)"123abc"123(int)"abc123"0(int)""0intval("123abc")123intval("abc123")0intval("")0(int)intval("0xff", 16)(int)$_GET['id']filter_var($_GET['id'], ...)Notice: Undefined index(int)$_GET['id']Undefined variableisset($_GET['id'])array_key_exists('id', $_GET)$id = filter_var($_GET['id'] ?? '', FILTER_VALIDATE_INT) ?: 1;?? ''?: 1?q=phppage(int)"" === 0