Laravel 11 中路由正则约束与参数验证是分层校验机制：前者在路由匹配阶段用 where() 或 Route::pattern() 限定 URL 参数格式，不匹配即返回 404；后者在控制器中通过 $request->validate() 或 FormRequest 校验业务数据，确保语义正确。两者须组合使用，缺一不可。
Laravel 11 中，路由正则约束和参数验证是两个不同层级的校验机制：前者在路由匹配阶段拦截非法 URL，后者在请求进入控制器后校验业务数据。它们目标一致——防止无效输入，但作用时机、范围和写法有明显区别。
路由正则约束：URL 层面的“第一道门”
它直接作用于路由定义，用 where() 或全局 Route::pattern() 限定参数格式，不匹配就 404，根本不会走到控制器或验证逻辑。
- 单参数约束：
Route::get('/user/{id}', ...)->where('id', '[0-9]+')—— 仅当 URL 是/user/123才匹配，/user/abc直接 404 - 多参数批量约束：
->where(['year' => '[0-9]{4}', 'slug' => '[a-z0-9\-]+']) - 全局复用：
Route::pattern('id', '[0-9]+')写在RouteServiceProvider::boot()，所有{id}自动生效
参数验证：控制器层的“业务守门员”
它发生在路由已成功匹配、控制器方法被调用之后，用于检查请求携带的实际数据（如表单字段、JSON body），支持更复杂的逻辑，比如数据库唯一性、关联存在性等。
- 内联验证：
$request->validate(['email' => 'required|email|unique:users']) - FormRequest 类验证：适合复杂场景，可复用、可授权、可自定义错误消息
- 自定义规则类：
php artisan make:rule UppercaseFirstLetter，适用于需跨多个接口复用的校验逻辑
为什么不能只靠其中一种？
只用正则约束，无法判断 {id} 对应的记录是否存在；只用参数验证，非法 URL（如 /post/abc）仍会触发完整请求生命周期，浪费资源且暴露接口结构。Laravel 11 推荐组合使用：用正则先筛掉明显非法格式，再用验证确保业务语义正确。
常见搭配示例
比如文章详情页：/post/{year}/{month}/{slug}
- 路由约束确保年月是数字、slug 符合 URL 规范：
->where(['year' => '[0-9]{4}', 'month' => '[0-9]{2}', 'slug' => '[a-z0-9\-]+']) - 控制器中再验证该
slug是否真实存在、是否已发布：Post::published()->whereSlug($slug)->firstOrFail()或配合validated()做额外字段校验
