request()->query()只取URL查询字符串参数，更安全；需白名单过滤字段、校验类型、处理范围/模糊搜索后缀，并排除空值和非法键，避免SQL错误或注入。
GET参数转查询条件时，request()->query() 和 request()->all() 有啥区别
直接用 request()->all() 会把 _token、_method 这类 Laravel 自带的隐藏字段也塞进查询条件，导致 SQL 报错或查出意外数据。而 request()->query() 只取原始 URL 查询字符串里的键值对，更干净。
- 如果表单是 GET 提交，用
request()->query()更安全 - 若混用了 POST 表单但 URL 带了 ?page=2 这类参数，
request()->query()仍能准确提取 -
request()->all()在 GET 场景下等于request()->query() + request()->except('_token')，但不推荐手动排除
过滤空值和无效字段避免 where('name', '') 这种错误查询
用户可能提交空字符串、"null" 字符串、0 或 null，直接丢给 where() 会导致查不到数据甚至全表扫描。Laravel 没有内置自动跳过空值的机制，得自己筛。
- 用
array_filter($params, fn($v) => !is_null($v) && $v !== '' && $v !== 'null' && $v !== 0)粗筛（注意：0 是合法值，按业务决定是否保留） - 更稳妥的做法是白名单过滤：
collect(request()->query())->only(['name', 'status', 'category_id'])，只允许指定字段参与查询 - 对数字字段如
status，建议额外加filter_var($v, FILTER_VALIDATE_INT)校验
支持范围查询和模糊搜索的字段要单独处理
URL 里传 ?created_at_from=2024-01-01&created_at_to=2024-12-31&name_like=admin 这类参数，不能直接套 where()。Laravel 的查询构造器不识别 _from / _to / _like 后缀。
- 遍历参数时检测后缀：
if (str_ends_with($key, '_from')) { $baseKey = str_replace('_from', '', $key); $builder->whereDate($baseKey, '>=', $value); } -
name_like要转成where('name', 'like', "%{$value}%")，注意 SQL 注入风险——$value必须经 Laravel 查询构造器自动转义，别拼字符串 - 避免在循环里反复调用
$builder->where(...)，应先归类再批量应用，否则易出逻辑错误
生成查询条件后，别忘了验证字段是否存在以防 SQL 错误
用户可能瞎改 URL，比如传个 ?xxx=123，而数据库根本没 xxx 字段，直接 where('xxx', 123) 会抛 SQLSTATE[42S22]: Column not found 异常。
- 提前定义允许的字段数组：
$allowed = ['name', 'email', 'status', 'created_at']; - 用
array_intersect_key($params, array_flip($allowed))做键级过滤 - 对日期范围、模糊搜索等衍生字段（如
created_at_from），也要在白名单里显式声明支持，而不是仅靠后缀判断
真正难的不是写几行 where()，而是想清楚哪些参数该进查询、哪些该忽略、哪些该报错——边界不划清，线上就容易 500。
