Laravel路由参数验证怎么做_Laravel路由参数验证的实现步骤【教程】
路由参数需用where()限定类型，防止非法路径进入控制器。Route::bind()仅绑定模型，不验证格式，应先用filter_var过滤。推荐使用表单请求类进行参数验证，API路由需重写failedValidation()返回JSON。验证只是第一道防线，不能替代模型查询与数据库约束。
路由参数验证这事儿，看似简单，但很多人就栽在这一步上。你想想，直接在路由定义里写个 {id}，Lara vel 默认全当字符串处理。不加点约束，/users/abc、/users/1%20 这种非法路径都能大摇大摆地进控制器，后面查数据库不是报错就是绕过了权限检查——这隐患可不小。
路由参数必须用 where() 限定类型才安全
说白了，where() 就是第一道防线。整数ID必须加 where('id', '[0-9]+')，别指望 ->middleware('throttle:api') 能替你挡住非法参数。UUID类型更得小心，正则表达式要写全：where('id', '[a-f0-9]{8}-[a-f0-9]{4}-[a-f0-9]{4}-[a-f0-9]{4}-[a-f0-9]{12}')——模型里那个 ->uuid() 只负责生成，不负责验证。至于中文路径参数，先确认Nginx或Apache正确转发了UTF-8编码，再用 where('name', '.*') 加控制器里 mb_strlen($name) 手动截断。
Lara vel 9+ 的 Route::bind() 不等于验证，只是绑定逻辑
很多人把 Route::bind() 当验证使，其实这招有风险。比如 Route::bind('user', function ($value) { return User::findOrFail($value); });，它只负责找模型，压根不校验 $value 是不是合法格式。万一 $value 是段SQL注入片段（比如 1 OR 1=1），findOrFail() 会直接抛异常，错误堆栈就把底层结构全暴露了。
实操建议：绑定前先过滤，把 Route::bind() 换成闭包里先做 filter_var($value, FILTER_VALIDATE_INT) 或正则匹配。避免在 bind() 里调用复杂查询——它会在每次匹配路由时执行，高并发下拖慢整个路由解析。如果要用软删除模型，findOrFail() 会失败，得改成 User::where('id', $value)->withTrashed()->firstOrFail()，但记得后续手动检查 trashed()。
用 Request 类做参数验证，别在控制器里手写 if (!is_numeric())
有人习惯在控制器里写 if (!is_numeric($id) || $id ，这种写法既重复又漏场景——浮点数 1.5 过了 is_numeric() 却插不进整型主键。Lara vel 的表单请求验证才是为这种场景设计的。
生成请求类：php artisan make:request GetUserRequest，在 rules() 里写 ['id' => ['required', 'integer', 'min:1']]。注意 integer 规则默认允许字符串数字（如 "123"），要严格类型用 'id' => ['required', 'int', 'min:1']（int 是 Lara vel 9.2+ 新增的严格整型规则）。批量验证多个参数时，别在 rules() 里硬编码字段名，用 request()->route()->parameters() 动态取，避免漏掉新增路由参数。
API 路由和 Web 路由的验证策略不能混用
Web 路由出错跳 404 页面，API 路由该返回 422 Unprocessable Entity。但很多人共用同一个 GetUserRequest，结果 API 请求带非法 ID 时返回 HTML 错误页，前端解析直接崩溃——这锅背得冤。
API 请求类继承 FormRequest 后，重写 failedValidation()，用 response()->json(..., 422) 替换默认行为。Web 路由用 validate() 方法，API 路由统一走 validated() + 自定义异常处理器，别依赖全局 App\Exceptions\Handler 一刀切。最关键的一点：别在 web.php 里注册 API 路由——中间件栈不同，VerifyCsrfToken 对 API 是冗余甚至有害的。
最容易被忽略的是：路由参数验证和模型查询是两层事。哪怕 where() 锁死了格式，find() 仍可能返回 null；哪怕 Request 类校验通过，数据库唯一索引冲突还是会发生。验证只是第一道门，不是保险柜。