$_get为空或参数缺失的常见原因包括：url参数未正确编码、web服务器重写规则丢失查询字符串、前端误用post发送参数、php配置禁用get；其值为原始字符串，需手动类型转换和安全过滤。
PHP中$_GET能直接拿到URL参数，但前提是请求方法为GET且参数已正确拼在URL上；如果收不到，大概率不是$_GET坏了，而是参数根本没传过来、被重写规则拦了，或者用了POST却误查$_GET。
为什么$_GET为空或不包含预期参数
常见现象：浏览器地址栏明明写了?id=123&name=test，但var_dump($_GET)输出空数组或缺字段。
- URL中参数名含非法字符（如空格、中文未编码），导致服务器解析失败——必须用
urlencode()或前端encodeURIComponent()处理后再拼接 - Web服务器配置了重写规则（如Apache的
.htaccess或Nginx的try_files），把带参数的URL重定向/重写成不带查询字符串的形式，例如/user/123→/user.php?id=123但漏掉了$args或QSA标志 - 前端用
fetch()或axios发请求时，错误地把参数塞进body（POST行为），却还去读$_GET——GET参数只能来自URL查询字符串 - PHP配置禁用了
$_GET（极罕见）：variables_order中不含G，可通过phpinfo()检查该值是否为EGPCS（含G）
$_GET中的值默认是未过滤、未转义的字符串
它直接映射URL解码后的原始输入，没有任何类型转换或安全处理——?num=0123拿到的是字符串"0123"，不是整数123；?flag=true拿到的是字符串"true"，不是布尔值。
- 需要整型？用
(int)或filter_var($val, FILTER_VALIDATE_INT)，别直接== 123 - 需要布尔？显式判断：
isset($_GET['debug']) && $_GET['debug'] === '1'比!empty($_GET['debug'])更可靠 - 涉及SQL或HTML输出？绝不能直接echo或拼接——先过
mysqli_real_escape_string()或PDO预处理，输出前用htmlspecialchars() - 注意
$_GET键名本身也来自用户输入，可能含点号、中括号等，PHP会自动转换为下划线（foo.bar→foo_bar），这是历史遗留行为，不可依赖
与$_REQUEST混用时的陷阱
很多人图省事用$_REQUEST统一收参，但它默认包含$_GET、$_POST和$_COOKIE，顺序由variables_order决定（默认EGPCS，即GET优先于POST）。
- 同名参数同时出现在URL和POST body里（比如
?id=1&name=a+ POST bodyid=2&email=b），$_REQUEST['id']取到的是1，不是2——这容易引发逻辑错乱 -
$_REQUEST无法区分来源，调试时看不出参数到底从哪来；线上出问题难复现 - 某些共享主机禁用
$_REQUEST（出于安全策略），代码会直接报Undefined variable - 明确知道来源就用对应超全局变量：
$_GET只用于显式GET参数，$_POST只用于表单提交，不要贪方便绕开语义
真正麻烦的从来不是$_GET本身，而是参数从浏览器发出那一刻起，经过编码、路由重写、代理转发、PHP解析多个环节后是否还完整。遇到拿不到值，先用$_SERVER['QUERY_STRING']确认原始查询字符串有没有，再逐层排查中间环节。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
