Laravel路由解析不是字符串匹配，而是构建含控制器、方法、参数、中间件及依赖注入准备的Route实例；匹配完成后该实例已ready-to-call，后续调用（如request()->route()）均为读取该预置对象。
路由解析不是字符串匹配，而是构建可执行上下文
Laravel 路由解析根本不是“找一条路径”，而是把一次 HTTP 请求完整转化为含控制器、方法、参数、中间件和依赖注入准备的 Route 实例。这个对象在匹配完成后就已 ready-to-call，后续所有调用（如 request()->route()）都是读取它。
关键动作发生在 Router::dispatch()：请求被封装为 Illuminate\Http\Request，然后按定义顺序遍历 RouteCollection，对每条路由并行执行四类验证器：UriValidator（路径正则）、MethodValidator（GET/POST 等）、SchemeValidator（http/https）、HostValidator（域名或子域）。全部通过才标记为“已匹配”。
容易踩的坑：
- 闭包路由无法被缓存——因为
routes-v7.php是预编译的 PHP 数组，不支持序列化匿名函数 - 路由定义顺序直接影响结果——先定义的路由会优先匹配，哪怕后定义的更精确
- 带参数的路由（如
/posts/{id}）必须等UriValidator提取参数值后，才能进入隐式绑定阶段
当前路由怎么拿到？本质是读取已写入的 Route 实例
匹配完成时，Route 实例已被写入当前 Request 对象和服务容器，所以任意位置都能安全读取：
-
request()->route()：从当前请求实例中直接取绑定的Route -
app('router')->current()：从Router服务中读最近一次匹配成功的Route -
Route::currentRouteName()：底层读的是Route对象的name属性（如'posts.show'）
注意：Route::current() 和 app('router')->current() 在绝大多数场景下等价，但若你在中间件里提前调用了 Router::dispatch()（比如手动重路由），app('router')->current() 可能返回旧值，而 request()->route() 更可靠。
隐式模型绑定不是“事后补救”，而是解析阶段的主动行为
隐式绑定（如 show(Post $post)）不是控制器调用前临时查库，而是发生在路由匹配成功后的参数绑定阶段。此时框架已知道 {post} 的值，并立即触发 Post::findOrFail($value) 或自定义 resolveRouteBinding()。
这阶段还同步完成：
- 所有类型提示参数（
Request、UploadedFile、自定义服务）都由服务容器注入 - 中间件数组（
web、auth等）被收集成管道，等待Pipeline执行 - 若模型重写了
getRouteKeyName()，查询字段会自动切换（比如用slug替代id）
常见错误：控制器方法签名写成 show($post)（无类型提示），或路由参数名是 {article} 但类型提示是 Post $post——两者不一致，绑定直接跳过，$post 就是原始字符串。
缓存路由跳过实时解析，但牺牲动态能力
启用路由缓存（php artisan route:cache）后，Laravel 直接加载 bootstrap/cache/routes-v7.php，里面是预编译的 Route 对象数组，不再走 UriValidator 等四步验证流程。
代价很明确：
- 闭包路由完全失效——缓存文件里无法保存匿名函数
- 运行时注册的路由（比如插件在
boot()里动态添加）不会被收录 -
Route::bind()和Route::model()注册的显式绑定逻辑仍有效，但它们本身必须在缓存生成前注册完毕
真正复杂的点在于：缓存只加速“匹配”，不加速“绑定”。即使路由已缓存，{user} 到 User 实例的数据库查询依然会发生——这是不可绕过的业务逻辑，不是解析开销。
