应使用类型提示的 request $request 获取 get 参数，而非 request::query() 或 request() 全局函数；前者安全可靠，后者在非 http 上下文中可能失效或报错。
别用 Request::query() 静态调用
静态调用 Request::query('key') 看似方便，但实际会返回 null 或抛出异常——因为 Laravel 的 Request 类不是设计为静态可调用的门面（Facade），它没有注册静态代理。你看到的 Request 门面其实是 Illuminate\Support\Facades\Request，但它只代理了少数方法（如 fullUrl()、ip()），不代理 query()、input()、post() 等取参方法。
常见错误现象：
- 本地开发可能“碰巧”不报错（因某些环境触发了自动注入或缓存），上线后突然失效
- 调用
Request::query('page')返回null，而request()->query('page')也一样不可靠（见下一条）
request() 全局函数在非控制器里也不安全
request() 是全局辅助函数，本质是调用服务容器里的当前请求实例。但它只在请求生命周期内有效，一旦脱离 HTTP 上下文（比如在命令行、队列任务、测试 setUp 中），就会返回空实例或报错。
使用场景限制明显：
- 控制器方法内部：可用，但不如类型提示清晰
- 中间件、事件监听器：勉强可用，需确保已进入请求栈
- Artisan 命令、模型观察者、Job handle()：不要用，此时
request()可能返回空对象，->query('x')直接报 Call to a member function query() on null
真正安全的 GET 参数获取方式
GET 参数本质是 URL 查询字符串，最稳妥的做法是明确来源、避免依赖上下文。优先级如下：
- 控制器中类型提示
Request $request，再调$request->query('page')或$request->input('page') - 需要在非请求上下文中读取（如命令行模拟请求），应显式构造 QueryString 或传参，而不是硬编码
request() - 若必须动态获取（比如封装工具函数），先判空：
if (app()->resolved('request') && request()->has('page')) { ... }，但这是兜底，不是推荐路径
注意：$request->input('page') 和 $request->query('page') 在纯 GET 请求中结果一致，但语义不同——前者可能被 POST/JSON 覆盖，后者严格限定来源，更符合“获取 URL 参数”的本意。
容易被忽略的边界点
GET 参数值始终是字符串，哪怕 URL 是 ?limit=100，$request->query('limit') 返回的仍是 '100'，不会自动转整型。如果后续要参与数值比较或数据库查询，必须手动 cast：(int) $request->query('limit', 10) 或用 $request->integer('limit', 10)。
另一个坑：路由参数（如 /users/{id}）和查询参数（?sort=name）是两回事。$request->query() 拿不到 {id}，得从路由绑定或 $request->route('id') 获取。
