有必要且低成本高回报：路由层正则约束可避免无效查询、减少执行开销、防御基础注入；where()适用于单路由，route::pattern()适合全局复用；需注意正则写法细节与校验边界。
{id} 被传入 abc 或 1' OR 1=1--，Laravel 会照常进入控制器，哪怕你后面用 findOrFail()，也已经触发了不必要的数据库查询或异常堆栈。
为什么 where() 比在控制器里 is_numeric() 更可靠
路由层匹配失败直接返回 404（或跳过该路由），根本不会走到控制器逻辑。这带来三个实际好处：
- 避免无效模型查询：比如
User::findOrFail('hello')会抛出ModelNotFoundException，而Route::get('/user/{id}')->where('id', '[0-9]+')根本不匹配，连 ORM 都不碰 - 减少中间件和控制器执行开销：非法请求在路由解析阶段就被筛掉，不消耗 session、auth、policy 等后续流程资源
- 防御基础注入试探：虽然不能替代 SQL 参数化，但能拦住明显畸形的输入，降低被扫描器盯上的概率
where() 和 Route::pattern() 该怎么选
看复用范围和维护成本：
- 单个路由临时加限制 → 用
->where('param', 'regex')，比如->where('slug', '[a-z0-9\-]+') - 多个路由共用同一参数名（如所有
{id}都应为数字）→ 在RouteServiceProvider::boot()里写Route::pattern('id', '[0-9]+')，一劳永逸 - 别混用两者去覆盖同一参数：如果全局定义了
Route::pattern('id', '[0-9]+')，又在某条路由上写->where('id', '\d{6}')，后者会覆盖前者——但可读性变差，容易误判
常见正则写法踩坑点
看似简单，但几个细节不注意就会失效：
-
[0-9]+不等价于\d+：PHP 的preg_match默认不启用 Unicode 模式，\d在某些环境可能匹配非 ASCII 数字，而[0-9]更稳妥 - UUID 约束别只写
[0-9a-f\-]{36}：它会匹配aaaaaaaa-bbbb-cccc-dddd-eeeeeeeeeeee这种非法格式，建议用完整版：[0-9a-f]{8}-[0-9a-f]{4}-[1-5][0-9a-f]{3}-[89ab][0-9a-f]{3}-[0-9a-f]{12} - 中文或特殊字符要显式放行：比如用户名允许中文+字母+数字，得写
[\x{4e00}-\x{9fa5}a-zA-Z0-9_]+并加上u修饰符，即->where('name', '[\x{4e00}-\x{9fa5}a-zA-Z0-9_]+u') - 末尾不要加
^和$：Laravel 内部已做全量匹配，写^[0-9]+$反而可能因内部封装逻辑导致意外行为
{id} 匹配了 123，不代表数据库里真有 ID=123 的记录。这个边界必须清楚：路由约束是第一道过滤网，不是最终校验。
