Laravel 的 request()->get('q') 通常已返回 URL 解码后的值，因 PHP 填充 $_GET 时默认调用 urldecode() 处理 %20 和 UTF-8 编码（如 %E4%B8%AD）；问题多源于前端重复编码、代理截断或误用 urldecode() 导致二次损坏，应优先用 rawurldecode() 按需解码并避免无脑套用。
Laravel 默认不自动对 GET 查询参数做 URL 解码，遇到 %20、%C3%A4 等编码值时，request()->get('q') 返回的是原始编码字符串，不是你想要的“中文”或带空格的可读文本——必须手动解码。
为什么 request()->get('q') 拿到的是 %20 而不是空格
Laravel 的 Request 对象底层调用 PHP 的 $_GET，而 PHP 在填充 $_GET 时已对 URL 查询字符串执行过一次 urldecode()。但这个解码仅限标准 ASCII 编码（如 %20 → 空格），对 UTF-8 多字节字符（如中文）的百分号编码（%E4%B8%AD）也正常处理。所以绝大多数情况下，你拿到的已经是解码后的值。
真正出问题的场景是：
- 前端重复编码：比如 JavaScript 里用了两次
encodeURIComponent()，导致传过来的是%2520（即%20被再编码了一次） - 代理或 CDN 提前截断/重写 URL，破坏了原始编码格式
- 从非标准入口（如 CLI 调用
Artisan::call()模拟请求）构造的请求未走完整解析流程
安全解码 GET 参数的三种做法
不要无脑套 urldecode() —— 它对已解码内容会损坏数据（如把空格再变成 +）。优先按需判断是否需要二次解码：
- 检查参数是否含连续
%序列（如%2520）：if (preg_match('/%[0-9A-Fa-f]{2}.*%[0-9A-Fa-f]{2}/', $raw)) { $decoded = rawurldecode($raw); } - 对明确需要 UTF-8 安全解码的字段（如搜索词），用
rawurldecode()替代urldecode()，它不把+当空格处理 - 在中间件中统一预处理（适合全站统一规则）：
$request->merge(['q' => rawurldecode($request->input('q', ''))]);
request()->query() 和 request()->input() 的行为差异
二者在 GET 场景下通常返回相同结果，但机制不同：
-
request()->query('q')只从$_GET读，不合并其他输入源 -
request()->input('q')会依次检查$_GET、$_POST、$request->json()，存在冲突风险（比如表单 POST 同名字段覆盖 GET） - 若你只处理纯 GET 请求，用
query()更语义清晰，也避免意外覆盖
注意：query() 返回值默认已是 PHP 自动解码过的，不需要再包一层 urldecode() —— 直接用就行。
容易被忽略的 Nginx/Apache 配置影响
Web 服务器可能在 Laravel 接收到请求前就拒绝或修改含特殊字符的 URL：
- Nginx 默认允许
%20，但若配置了underscores_in_headers on或自定义location正则，可能提前 400 或 404 - Apache 的
AllowEncodedSlashes设置会影响路径中%2F的处理，虽不直接作用于查询参数，但整条 URL 异常会导致参数丢失 - 验证方式：查看
access.log中记录的原始请求行，确认?q=hello%20world是否完整到达 Laravel
真正在框架层“拿不到解码后内容”的情况极少；多数时候问题出在前端多编码、反向代理误处理，或开发者误以为框架该做而没做——其实它早就做了。
