资源路由的 index 方法不接收查询参数，必须通过 Request 对象的 input() 或 query() 方法获取；正确签名是 public function index(Request $request)，且 Request 必须为首个参数；复杂查询应拆分为专用路由或请求类。
资源路由默认不处理查询参数，index 方法只接收空参数
资源控制器（如 php artisan make:controller PostController --resource）生成的 index 方法签名是 public function index()，它本身不声明任何参数。Laravel 不会把 URL 查询字符串（如 ?search=laravel&page=2）自动注入为方法参数——那不是路由参数，而是请求数据。
常见错误是试图写成 public function index($search) 或 public function index(Request $request, $search)，结果要么报错“Too few arguments”，要么 $search 始终为 null。
- 查询参数必须通过
$request实例获取，不能靠方法签名接收 - 资源路由的
index方法天然适配 GET 查询，只要在方法体内用$request->input()或$request->query()读取即可 - 若需类型安全或默认值，优先用
$request->input('key', 'default')，它比$request->query()更通用（兼容表单、JSON、query）
Request 注入位置必须是第一个参数，且不能省略类型提示
要在资源控制器里用 Request 对象，必须显式声明类型提示，并放在参数列表最前面。Laravel 的服务容器按顺序解析依赖，Request 必须由框架注入，不能靠手动传参或后置放置。
错误写法示例：public function index($id, Request $request) —— 这会导致 $id 被误认为是路由参数（但资源路由 index 根本没定义 {id}），$request 反而无法注入。
- 正确签名：
public function index(Request $request) - 如果同时需要分页、搜索、排序等多参数，直接用
$request->only(['search', 'sort', 'per_page'])批量提取 - 避免用
$_GET或Input::get()：前者绕过 Laravel 请求生命周期，后者已废弃（Laravel 5.2+ 不再推荐）
带查询参数的 URL 不影响资源路由匹配，但要注意中间件顺序
资源路由对查询参数完全透明。访问 /posts?category=php&published=1 仍会命中 PostController@index，前提是路由定义是 Route::resource('posts', PostController::class)。但中间件执行顺序可能干扰参数读取。
典型陷阱：自定义中间件在 VerifyCsrfToken 之前修改了请求体，或在 TrimStrings 之后读取了未被 trim 的原始值。
- 确保
App\Http\Kernel.php中$middlewareGroups['web']里TrimStrings和ConvertEmptyStringsToNull在你自定义中间件之前 - 调试时可用
dd($request->all())确认查询参数是否出现在输出中；如果为空，先检查浏览器地址栏是否真带了?和参数，再查中间件是否意外覆盖了$request - 不要在中间件里调用
$request->query()后又返回新$request实例——这会切断后续控制器对原始查询参数的访问
复杂查询场景下，别硬塞进 index，考虑单独路由或请求对象封装
当查询逻辑变重（如全文搜索 + 多条件过滤 + 导出开关），把所有参数塞进 index 方法会让代码难维护。这不是配置问题，而是设计边界。
例如，导出 Excel 不该和普通列表共用一个响应格式，也不该共享分页逻辑。
- 新增专用路由：
Route::get('/posts/export', [PostController::class, 'export'])，对应独立方法 - 用表单提交替代长 URL 查询：POST 到
/posts/search，避免 URL 长度限制和缓存干扰 - 重度复用时可定义请求类：
php artisan make:request SearchPostsRequest，在rules()和authorize()中集中约束参数，控制器里直接接收该对象
真正容易被忽略的是：资源控制器的「约定」只管 CRUD 路由结构，不管你怎么用请求数据。一旦开始拼接复杂查询，就该跳出 index 的舒适区，而不是反复调整参数获取方式。
