用 request() 门面拿不到 GET 参数是因为它默认合并所有输入源而非仅查询字符串，真正获取 GET 参数应使用 $request->query('key')，该方法严格限定从 URL 查询字符串取值，避免 POST 或 JSON 数据干扰。
为什么用 request() 门面拿不到 GET 参数？
直接调用 request('key') 确实能取到 GET 参数，但前提是当前请求确实是 GET 类型，且参数在 URL 查询字符串里。很多人踩坑是因为混用了 POST 表单提交、AJAX 的 Content-Type: application/json，或者忘了 Laravel 的 request() 默认只从当前请求的全部输入源（query + post + files）合并取值，不区分来源 —— 这看似方便，实则掩盖了参数来源模糊的问题。
真正需要明确取 GET 参数时，应该用更精准的方式。
-
request()->query('key')：只从查询字符串（?key=value）中取值，POST 提交或 JSON body 里的同名字段不会干扰 -
request()->input('key')：合并所有输入源，等价于request('key')，但语义更清晰 - 如果路由定义了参数（如
/user/{id}），request()->route('id')或request()->segment(2)才是正确方式，不是query()
Request 门面和 request() 辅助函数有啥区别？
两者底层都指向同一个 Illuminate\Http\Request 实例，但调用路径不同：Request 是门面类，需 use Illuminate\Support\Facades\Request;；request() 是全局辅助函数，无需导入。实际效果几乎一样，但门面写法在 IDE 中更容易跳转和补全。
注意：门面方式必须确保已注册服务提供者（默认已注册），否则会抛出 Class 'Request' not found 错误。
- 推荐用
request()->query('page')，简洁且无命名冲突风险 - 若已在控制器方法签名中注入
Request $request，就别再用门面或辅助函数，直接用$request->query('page') - 门面在非 Laravel 环境（如单元测试 mock）中更难替换，辅助函数也一样 —— 真要解耦，优先考虑依赖注入
GET 参数为空时怎么安全取值？
request()->query('sort') 返回 null 而不是报错，但如果你期望默认值，别手动写 ?? 'asc'，Laravel 提供了更一致的方式：
-
request()->query('sort', 'asc')：第二个参数是默认值，仅当键不存在或值为null时生效 -
request()->query('limit', 10)：默认值支持数字，返回的是整型（不是字符串），避免后续类型判断 - 慎用
request()->query('filter') ?: 'all'—— 如果filter=0或filter=''，这个表达式会误判为 false
另外，request()->has('page') 判断的是键是否存在（不管值是否为空字符串），而 filled('page') 才会过滤掉空字符串和 0 等“falsy”值。
中文参数或特殊字符 GET 传参乱码怎么办？
Laravel 默认使用 UTF-8 编码，但浏览器对 URL 编码规则不一致，尤其在中文、空格、斜杠等字符上。后端拿到的 request()->query('q') 可能是原始编码（如 GBK）或双重编码，导致显示为乱码或解码失败。
- 前端必须用
encodeURIComponent('张三')编码，而不是encodeURI（后者不编码/ ? & =） - PHP 的
$_GET在php.ini中若设置了default_charset = "GBK"，会导致自动转码错误，应统一设为UTF-8 - Laravel 不会自动重解码已解码的 query —— 如果你发现
%E5%BC%A0%E4%B8%89变成了å¼ ä¸，说明被重复 decode 了，检查是否有自定义中间件或urldecode()手动调用
最稳妥的做法：前端严格 UTF-8 编码，后端一律信任 request()->query() 返回值，不做额外 decode。
