$_GET为空的主因是URL无查询参数，如访问test.php而非test.php?id=123；其他原因包括前端将参数误放请求体、参数名拼写错误、空值、Nginx重写丢弃$args等。
PHP中$_GET为空的常见原因
直接访问 $_GET 却拿不到值，不是代码写错了，而是请求根本没带参数过去。最典型的情况是：URL里压根没有 ?key=value 这部分，比如访问的是 http://example.com/test.php 而不是 http://example.com/test.php?id=123。这时候 $_GET 就是空数组，isset($_GET['id']) 也会返回 false。
其他高频原因包括：
- 前端用
fetch或axios发送 GET 请求时，把参数塞进了 request body（错误做法），而 PHP 的$_GET只读 URL 查询字符串 - URL 中参数名拼写错误，比如 PHP 里写
$_GET['user_id']，但实际传的是?uid=5 - 参数值为空字符串（
?name=），此时$_GET['name']是''，不是unset，但empty()会判为真 - Web 服务器（如 Nginx）配置了重写规则，把查询参数意外丢弃了，比如用了
try_files $uri =404;却没保留$args
如何安全地获取并判断 GET 参数
别一上来就用 $_GET['xxx']，它可能触发 Notice；也别只靠 empty()，它会把 '0'、0、false 都当成“空”，而有时 id=0 是合法值。
推荐组合判断方式：
立即学习“PHP免费学习笔记（深入）”；
- 用
isset($_GET['key'])确认参数是否存在（哪怕值是''或0） - 再用
$_GET['key'] !== ''判断是否非空字符串（若业务不允许空字符串） - 需要转类型时，显式过滤：比如
$id = filter_input(INPUT_GET, 'id', FILTER_VALIDATE_INT);，失败时返回false，比手动(int)强制转换更可靠 - 调试时加一句
var_dump($_GET);，确认服务器端到底收到了什么——有时候问题出在前端没发，而不是 PHP 没收到
Nginx 下 GET 参数丢失的排查与修复
如果你确定 URL 带了参数（比如 /page.php?test=1），但 $_GET 始终为空，大概率是 Nginx 配置问题。默认的重写规则常会吃掉 $args。
检查 location 块中是否有类似下面的写法：
try_files $uri $uri/ /index.php;
这行会丢弃原始查询参数。正确写法是显式带上 $args：
try_files $uri $uri/ /index.php?$args;
改完记得 nginx -t && nginx -s reload。Apache 一般不出现这类问题，除非用了自定义 RewriteRule 且没加 [QSA] 标志。
GET 参数含特殊字符或中文时的注意事项
浏览器会对 URL 中的空格、中文、&、= 等自动编码（如 姓名=张三 → %E5%A7%93%E5%90%8D=%E5%BC%A0%E4%B8%89），PHP 默认能自动解码进 $_GET。但如果前端用 encodeURIComponent 多编了一次，或者后端被某些中间件（如某些 CDN 或 WAF）二次解码，就可能导致乱码或截断。
验证方法：
- 打印
urlencode()后的原始 URL，看是否过度编码 - 检查
$_SERVER['QUERY_STRING']，它保持原始未解码状态，可对比判断是否被提前处理过 - 避免在 PHP 中对
$_GET值再调用urldecode()，PHP 已完成一次标准解码
真正难搞的是某些老旧系统或嵌入式设备发来的请求，它们可能不遵循 RFC 编码规范，这时就得靠 $_SERVER['QUERY_STRING'] 手动解析，再用 parse_str() 安全处理。
