PHP获取URL参数主要有三种方式：一是用$_GET读取查询字符串，但仅限?后参数且+变空格；二是通过服务器重写规则将伪静态路径映射为$_GET参数；三是解析$_SERVER['REQUEST_URI']并结合正则提取路径段，避免explode的脆弱性。
PHP中获取URL参数的三种基础方式
直接用 $_GET 最常用，但必须清楚它只解析 URL 中 ? 后面的键值对，且不自动解码空格或加号。比如访问 /user.php?id=123&name=John+Doe，$_GET['name'] 实际是 "John Doe"（+ 被转为空格），但若参数本身含原始 %2B，就得手动 urldecode()。
如果 URL 是伪静态形式，如 /user/123，$_GET 拿不到任何东西——这时得靠 Web 服务器重写规则把路径段映射成查询参数，或在 PHP 中解析 $_SERVER['REQUEST_URI']。
另外，parse_url() 和 parse_str() 组合可用于处理非标准 URL 字符串（比如从日志里提取的完整 URL），但注意 parse_str() 默认会覆盖已有变量，务必传入第二个参数接收结果：
parse_str(parse_url($url, PHP_URL_QUERY), $params);
$_GET 和 $_REQUEST 的关键区别与风险
$_GET 只读取 URL 查询字符串；$_REQUEST 默认包含 $_GET、$_POST 和 $_COOKIE，顺序由 php.ini 中的 request_order 决定（默认 "GP"，即 GET 优先于 POST）。这意味着同名参数下，$_REQUEST['id'] 可能被意外覆盖。
立即学习“PHP免费学习笔记（深入）”；
更危险的是：如果开启了 register_globals（已废弃，但旧环境可能残留），或用了某些框架的自动绑定机制，未过滤的 $_GET 值可能直接变成全局变量，导致变量污染。
实际开发中应坚持：
- 始终用
$_GET明确来源，不用$_REQUEST - 对每个参数做
isset()或filter_input(INPUT_GET, 'key')判断存在性 - 避免直接 echo
$_GET值，防止 XSS，至少过htmlspecialchars()
处理带数组语法的 URL 参数（如 ?filter[status]=active&filter[type]=user）
PHP 原生支持方括号语法，$_GET['filter'] 会自动变成关联数组：['status' => 'active', 'type' => 'user']。但这仅限于简单一层嵌套；多层如 ?data[user][id]=123 也能解析，但深度过大时容易触发 max_input_vars 限制（默认 1000），导致截断。
常见陷阱：
-
前端用 JS 构造 URL 时误用
encodeURIComponent('{ "a": 1 }')，后端收到的是 JSON 字符串而非结构化数据，$_GET不会自动解析 JSON - 参数名含点号（
user.name）会被 PHP 自动转为下划线（user_name），这是历史兼容行为，无法关闭 - 空数组参数如
?ids[]=会生成$_GET['ids'] = ['']，不是[]，需额外判断
伪静态路由下如何安全提取路径参数
当使用 Apache 的 RewriteRule ^user/([0-9]+)$ user.php?id=$1 [L] 或 Nginx 的 rewrite ^/user/(\d+)$ /user.php?id=$1 break; 时，参数最终仍进 $_GET，无需手动解析。
但如果没配重写，又想支持 /user/123 这种路径，就得自己切 $_SERVER['REQUEST_URI']：
$path = parse_url($_SERVER['REQUEST_URI'], PHP_URL_PATH);
$segments = array_filter(explode('/', $path));
$id = $segments[2] ?? null;
这段代码脆弱点明显：依赖路径层级固定、没处理 URL 编码、没校验数字格式。更稳妥的做法是用正则匹配关键段，或引入轻量路由库（如 AltoRouter），而不是手写 explode。
特别注意：$_SERVER['REQUEST_URI'] 可能含查询参数（如 /user/123?tab=profile），直接 explode 会把 tab=profile 当作路径段，必须先剥离。
