不会自动出错，但可能存错或查不准；Laravel的Request对象已自动解码（如%20→空格），$request->input('q')返回“人话”字符串，入库时应直接传给Eloquent或Query Builder（预处理防SQL注入），切勿手动addslashes()或urldecode()。
GET参数含%20、+、/等符号时，直接入库会出问题吗
不会自动出错，但可能存错或查不准。Laravel 的 Request 对象默认已对 URL 编码做解码（如 %20 → 空格，+ → 空格），所以 $request->input('q') 拿到的是“人话”字符串，不是原始编码串。但问题出在后续环节：如果这个值直接拼进 SQL、用作文件名、或传给 shell 命令，就可能因空格、斜杠、单引号等触发意外行为。
入库前要不要手动 urldecode() 或 addslashes()
完全不需要，而且危险。Laravel 的查询构建器和 Eloquent 默认使用预处理语句，where('title', $request->input('q')) 这类写法中，$request->input('q') 的值会被安全绑定为参数，无论它含多少个空格、单引号或反斜杠，都不会破坏 SQL 语法。手动 addslashes() 反而会让数据多一层转义，导致库里存的是 O\'Reilly 而不是 O'Reilly。
- ✅ 正确做法：直接传给 Eloquent 或 Query Builder 方法（
where、update、insert） - ❌ 错误做法：
DB::statement("INSERT INTO ... VALUES ('" . addslashes($q) . "')") - ⚠️ 注意：
DB::raw()和selectRaw()不走参数绑定，一旦拼接用户输入，立刻高危
哪些场景必须额外转义或验证
当 GET 参数不进数据库，而是用于其他上下文时，才需针对性处理：
Laravel Cloud
下载
Laravel Cloud（cloud.laravel.com）。此技能用于处理所有 Laravel Cloud 请求，包括搜索和读取数据。只要任务涉及 Laravel Cloud，即使用此技能。
- 用作文件路径：
storage_path('logs/' . $request->input('date'))→ 必须过滤掉../、/、\0，推荐用白名单正则：preg_match('/^\d{4}-\d{2}-\d{2}$/', $date) - 传给
exec()或shell_exec()→ 必须用escapeshellarg()包裹，不能靠urldecode或strip_tags - 作为 Blade 模板里的 JS 变量：
<script>const q = "{{ $q }}";</script>→ Blade 默认转义 HTML，但 JS 字符串需额外@json($q)，否则引号或换行会崩语法 - 用在
ORDER BY或GROUP BY字段名 → 不能直接拼，必须走白名单校验（如in:created_at,updated_at,name）
调试时怎么确认 GET 参数真实值
别信浏览器地址栏显示的编码形式，也别只看 dd($request->all()) —— 它显示的是已解码后的值。要确认原始传输内容，得看底层：
- 查原始查询字符串：
$request->server('QUERY_STRING')（返回q=hello%20world&sort=name） - 对比解码前后：
urldecode($request->server('QUERY_STRING'))vs$request->fullUrl() - 检查是否被中间件修改过：比如某些 SEO 中间件会重写 URL，导致
$request拿到的已是处理后版本
最易忽略的是：同一个参数名在 query 和 post 同时存在时，$request->input() 会优先取 POST，除非你明确用 $request->query()。这点在调试表单回显逻辑时经常翻车。
