应优先用$request->query('key')或$request->query->get('key')获取GET参数，因其仅读URL查询字符串、语义明确、避免POST/JSON数据覆盖；input()会合并多源数据，行为不可控。
直接用 request() 或 request()->query() 最稳妥，别依赖 input() —— 它默认合并 POST/GET/文件，容易覆盖或混淆。
为什么 request()->get() 比 request()->input() 更适合取 GET 参数
request()->input() 会从所有请求源（POST body、GET query string、route parameters）里找键，顺序固定但不透明；而 request()->get() 是 request()->query->get() 的快捷方式，只查 URL 查询参数，语义明确、行为可预测。
- GET 请求中传
?page=2&sort=name，request()->get('page')返回"2"，request()->input('page')也返回"2"—— 表面一样，但一旦同时提交同名 POST 字段，结果就不可控 -
request()->get('page', 1)支持默认值，request()->input('page', 1)也支持，但后者在 POST 有page字段时会优先取它，不是你想要的“仅 GET 默认” - Laravel 9+ 中
request()->query是Symfony\Component\HttpFoundation\ParameterBag实例，get()是其原生方法，无额外封装开销
request()->query->all() 和 request()->query()->all() 有区别吗
有。前者是正确写法；后者会报错：Call to undefined method Illuminate\Http\Request::query() —— 因为 query 是属性，不是方法。
-
request()->query->all()返回完整 GET 参数数组（键值全为字符串） -
request()->query->has('search')比isset(request()->query->search)更安全，能处理空字符串、null等边界 - 不要用
$_GET：绕过 Laravel 的请求生命周期，丢失类型转换、过滤、测试模拟能力
在控制器方法参数里自动注入 GET 参数靠谱吗
不推荐直接绑定查询参数。Laravel 的依赖注入容器只解析路由参数和请求体，不解析 query string。
- 写
public function index(Request $request, $page)不会把?page=3自动塞进$page—— 这个$page来自路由定义如/posts/{page}，和 GET 无关 - 想类型安全地取 GET 值，用
request()->integer('page')或request()->boolean('active')，它们会强制转换并抛出InvalidArgumentException（可被异常处理器捕获） - 复杂筛选场景建议封装成 Request 类，用
rules()验证query，比零散调用更易维护
真正容易被忽略的是：当 Nginx 或 CDN 做了 URL 重写，或前端用 history.pushState 改变地址栏但没触发新请求时，request()->query 读到的仍是上一次请求的参数——它永远反映服务器收到的那个 HTTP 请求的原始 query string，不会动态响应前端地址栏变化。
