TrimStrings中间件不处理$_GET是因为其源码仅针对$_POST和$request->all()，明确跳过QUERY_STRING数据；需手动用trim()或正则清理，并在Nginx/Apache层规范URL以防缓存键污染。
为什么$_GET里的空格没被TrimStrings中间件处理
因为Laravel的TrimStrings中间件**只处理$_POST和$request->all()，不碰$_GET**。它在App\Http\Kernel里注册为全局中间件，但源码里明确跳过了QUERY_STRING相关数据。你用dd($_GET)看到name => " john doe "，中间件根本不会动它——这不是bug，是设计如此。
常见错误现象：request()->input('name')返回带空格值，但request()->query('name')或直接$_GET['name']仍是原样；有人误以为开了TrimStrings就一劳永逸，结果搜索功能匹配失败、权限校验绕过。
手动清理$_GET参数的三种安全写法
别改框架底层，用轻量封装。推荐统一收口到一个辅助函数，避免到处重复trim()：
-
trim($_GET[$key] ?? '')：最简，但仅去首尾，中间空格保留；适合纯ID类参数（如?id= 123） -
preg_replace('/\s+/', ' ', trim($_GET[$key] ?? ''))：压缩连续空白为单空格，再trim；适合搜索关键词（?q= hello world→hello world） -
filter_var($_GET[$key], FILTER_SANITIZE_STRING)：PHP 8.1+已弃用，且会删掉所有HTML标签但不处理多余空格，**不推荐**
注意：filter_input(INPUT_GET, $key, FILTER_SANITIZE_FULL_SPECIAL_CHARS)可防XSS，但不清理空格；如需兼顾安全与格式，得组合调用。
Laravel请求对象里query()方法的陷阱
$request->query('name')本质是array_key_exists('name', $_GET) ? $_GET['name'] : null，**不做任何过滤**。它比直接读$_GET唯一优势是支持默认值：$request->query('name', 'default')。
容易踩的坑：
- 混用
input()和query()：前者走TrimStrings流程（只对POST生效），后者直取$_GET，导致同一参数在不同方法里值不一致 - 依赖
request()->all()想拿到GET参数：它默认只合并POST+FILES，GET需显式加->merge($request->query()) - 在路由模型绑定或策略中直接用
$request->query('id')做查询：空格未清理可能触发全表扫描或匹配不到记录
生产环境必须加的两道防线
单纯trim不够。真实业务里GET参数常来自用户手输URL、第三方跳转或旧系统对接，要防住边界情况：
- 对关键参数（如
user_id、token）加filter_var($val, FILTER_VALIDATE_INT)或ctype_alnum()校验，空格清理后立刻验证类型 - 在Nginx/Apache层加
rewrite规则，把含连续空格的URI 301跳转到规范URL（例如/search?q=hello%20%20world→/search?q=hello%20world），从源头减少脏数据进入PHP
最易被忽略的一点：缓存键生成时若拼接了未trim的$_GET值，会导致相同语义的请求被当成不同key缓存，浪费内存且增加穿透率。
