PHP原生解析嵌套URL参数需依赖SAPI行为（如Apache+mod_php支持，Nginx+PHP-FPM需确保fastcgi_param配置正确）；Laravel中应使用request('filter.name')而非request('filter')获取值，校验用filled()而非has()，批量处理推荐$request->input('filter', [])配合Arr::only()。
PHP原生如何解析嵌套URL参数
浏览器发起的 ?filter[name]=john&filter[age]=25 请求，Laravel底层用的是 PHP 原生的 $_GET，但 PHP 默认不会自动展开成多维数组——它只在 php.ini 中开启 arg_separator.input = & 且 variables_order 包含 G 时才接收，而数组语法（方括号）是否生效，取决于 CGI/CLI 模式和 SAPI 行为。Apache + mod_php 通常能正确解析，但 Nginx + PHP-FPM 需确认 fastcgi_param QUERY_STRING $query_string; 未被篡改。
Laravel中用request()取嵌套GET参数的正确写法
直接写 request('filter') 会返回 null 或字符串，因为 Laravel 的 request() 辅助函数默认不递归解析方括号结构；必须显式用点号路径访问：
-
request('filter.name')→ 返回'john' -
request('filter.age')→ 返回25 -
request('filter')→ 返回整个filter数组（仅当该 key 在原始$_GET中已作为数组存在）
注意：如果 URL 是 ?filter[name]=john（即编码后的 [ 和 ]），Laravel 自动解码并重建结构，无需手动 urldecode()。
验证嵌套参数是否存在时别踩has()的坑
request()->has('filter.name') 看似合理，但实际会失败——has() 不支持点号路径校验嵌套键，它只查一级 key。正确方式是：
- 用
filled('filter.name')（推荐，同时判非空） - 或先取
$filter = request('filter', [])，再用isset($filter['name']) - 避免
request()->has('filter')后直接request('filter.name')，因为filter可能是字符串而非数组（如用户恶意传?filter=abc）
批量处理嵌套GET参数时用input()更安全
若需整个 filter 子树，别用 request()->all()——它可能混入其他无关参数。应明确指定：
$filter = request()->input('filter', []);
这会确保返回数组类型，即使原始请求里 filter 缺失或为 null。再配合 Arr::only($filter, ['name', 'age', 'status']) 过滤字段，比手动 array_filter 更可靠。
真正容易被忽略的是：前端 JavaScript 构建 URL 时若用 URLSearchParams 直接 append filter[name]，某些旧版 Safari 会 double-encode 方括号，导致后端收到 filter%255Bname%255D，这时 Laravel 解码一次仍得 filter[name]，最终无法匹配。务必在前端用 encodeURIComponent('filter[name]') 而非依赖自动编码。
