路由参数必须用where()或Route::pattern()约束，否则/{id}等动态段无格式校验，/users/abc也能匹配并触发异常；where()用于URL格式校验，业务语义校验应交由控制器validate()处理，返回422而非误导性404。
不加 where() 的路由参数，等于裸奔——/user/abc 会直接进控制器，查不到数据、抛异常、甚至暴露逻辑路径。
路由参数必须用 where() 或 Route::pattern() 约束
URL 中的动态段（如 {id}、{slug}）默认不做任何格式校验，框架原样接收字符串。这意味着：
-
/users/123和/users/abc都能匹配Route::get('/users/{id}')，后者进控制器后可能触发ModelNotFoundException或 SQL 错误 - 攻击者可用
/posts/1%20（空格编码）、/api/v1/order/..%2Fetc%2Fpasswd绕过业务层判断，试探路径或注入 - 没有正则约束的参数，连
404都不是“安全失败”，而是把错误甩给后续逻辑
正确做法是在路由定义阶段就拦截：
Route::get('/user/{id}', [UserController::class, 'show'])
->where('id', '[0-9]+'); // 只允许纯数字
或批量约束：
Route::get('/blog/{year}/{slug}', [PostController::class, 'byYearAndSlug'])
->where(['year' => '[0-9]{4}', 'slug' => '[a-z0-9-]+']);
Route::pattern() 全局复用与局部覆盖优先级
全局规则写在 app/Providers/RouteServiceProvider.php 的 boot() 方法里，对所有同名参数生效：
Route::pattern('id', '[0-9]+');
但单条路由的 ->where('id', ...) 会覆盖全局规则——这是明确的设计行为，不是 bug：
- 全局设
id为数字 → 所有{id}默认只认123 - 某条管理路由写
->where('id', '[a-z]+')→ 此处{id}只认字母，比如/admin/user/abc - 没被
pattern()或where()声明的参数（如{token}）完全无校验，一律按原始字符串接收
API 路由别用 where() 做业务校验
RESTful API 的设计原则是：404 表示资源不存在，422 表示请求数据语义错误。而 where() 匹配失败返回 404，这在 API 场景下容易误导：
-
GET /api/users/abc→where('id', '[0-9]+')失败 → 404 → 前端以为“用户不存在”，实际是“ID 格式非法” - 正确做法：放开路由匹配（去掉
where），让请求进控制器，再用FormRequest或$request->validate()校验并返回 422 - 例如：
'id' => 'required|integer|min:1'，错误信息可明确提示 “ID 必须为正整数”
一句话：URL 层校验（where）管格式，业务层校验（validate）管语义，两者不能混用。
正则写法常见坑与性能注意点
看似简单，但几个细节常导致失效或隐患：
-
->where('id', 'd+')在 PHP 字符串中需双反斜杠：'\d+'，否则会被当转义字符吃掉 -
[0-9]+不等价于d+：前者只匹配 ASCII 数字，后者在 PCRE 下可能匹配 Unicode 数字（如阿拉伯数字），Laravel 默认不启用u修饰符，建议统一用[0-9] - 正则太复杂（如嵌套量词、回溯多）可能引发 ReDoS，避免写
.*?类模糊匹配，尤其在高并发路由上 -
where()校验发生在路由匹配阶段，不查数据库、不执行中间件，开销极低；但一旦写错正则，整个路由就无法命中，调试时注意查看是否被其他更宽泛的路由抢了先
真正容易被忽略的，是「未声明参数完全无校验」这个事实——它不像 PHP 类型声明那样报错，而是静默放行，直到控制器里 find() 返回 null 或 DB 报错才暴露问题。
