清洗应按需分层进行，避免统一处理request()->all()导致合法值丢失；request()->query()适合URL参数精简，需保留0和"0"；验证规则已含清洗语义，重复处理易掩盖问题。
有必要，但清洗动作不该放在请求刚进来时统一做，而应按需、分层、有选择地做——否则容易把合法值（比如 0、"0"、false）误删，或干扰后续验证逻辑。
request()->all() 和 request()->query() 的清洗时机完全不同
很多人一上来就对 request()->all() 调用 array_filter，这是危险操作。因为 request()->all() 已经过 TrimStrings 等全局中间件处理，还混入了 POST、route 参数甚至文件对象，直接过滤会破坏结构、丢失类型信息。
-
request()->query()才是纯 GET 查询参数的原始映射，适合做 URL 级精简 - 若你只处理分页、筛选类参数（如
?status=0&category=tech），应只清洗request()->query()，且必须排除空字符串和null，保留0和"0" - 老版本 Laravel 不支持 Collection 的
filter()方法？用collect(request()->query())->filter(fn($v) => trim((string)$v) !== '')->all()更稳妥
array_filter($_GET) 默认行为会吃掉 0 和 "0"
PHP 原生 array_filter($_GET) 是基于 falsy 判断的，0、"0"、false、'' 全部被剔除。但业务中 ?status=0 很可能表示“待审核”状态，不是空值。
- 正确写法是显式判断：
array_filter($_GET, fn($v) => $v !== '' && $v !== null) - 如果还要兼容空白字符串（如
" "），改成trim((string)$v) !== ''，注意强制转 string 防 PHP 8.1+ 的TypeError - 别忘了兜底：
is_array($_GET) ? $_GET : []，Nginx + PHP-FPM 某些配置下$_GET可能为null
验证规则本身已含清洗语义，重复清洗反而坏事
Laravel 的 validate() 或 FormRequest 规则（如 required|string|email）在底层会自动 cast 和 normalize 数据。例如 integer 规则会尝试转整型，boolean 会识别 "1"、"true"、1 等等。
- 你在控制器里先
array_map('trim', request()->all())，再进validate()，等于做了两遍类型处理，可能掩盖真实输入问题 -
TrimStrings中间件已对字符串字段做了首尾去空，不需要你在业务层再 trim 一遍 - 真正该清洗的，是那些不走验证流程的字段（比如手动取的
request()->query('q')），或要透传给第三方 SDK 的原始参数
最易被忽略的一点：清洗和验证不是替代关系，而是协作关系。清洗解决“数据形状”，验证解决“数据意义”。一个 0 是否该保留，取决于它在业务中是“有效值”还是“占位符”——这个判断无法交给通用函数，得由你写在具体逻辑里。
