显式模型绑定必须用于非主键字段查找、软删除/状态过滤、未找到时自定义处理、路由组内局部覆盖等场景；它通过route::bind()或route::model()集中控制解析逻辑，覆盖隐式绑定。
显式模型绑定不是“要不要用”，而是“什么时候必须用”——当你无法靠参数名和主键 ID 完成自动解析时，就得上。
需要按非主键字段查找模型（比如 slug、username、uuid）
隐式绑定只认 id 字段，且要求路由参数名和模型类名一致（如 {user} → User）。一旦你想用语义化 URL，比如 /posts/laravel-routing-guide，就必须让 {post} 绑定到 Post::where('slug', $value) 而不是 Post::find($value)。
Route::bind('post', function ($value) { return \App\Models\Post::where('slug', $value)->firstOrFail(); });- 注意：
Route::bind()的第一个参数是路由参数名（post），不是模型类名；它和{post}对应，不是和Post类名强绑定 - 如果写成
Route::bind('slug', ...)，那路由就得是/posts/{slug}，参数名变了，控制器签名也得跟着变
需要统一处理软删除模型的可见性逻辑
默认隐式绑定会查出已软删除的记录（withTrashed() 不启用时直接 404），但业务常要求“已删除的不参与路由解析”。显式绑定能让你在闭包里加 ->withoutTrashed() 或自定义状态过滤。
- 例如：只允许状态为
published的文章被路由解析：Post::where('slug', $value)->where('status', 'published')->firstOrFail() - 这种逻辑没法塞进隐式绑定，也没法靠模型的
resolveRouteBinding()方法全局覆盖（因为该方法只接收单个值，不便于加多条件） - 别在每个控制器里重复写
->where(...)，显式绑定是集中收口的位置
需要拦截并重写模型未找到时的行为
隐式绑定失败直接抛 ModelNotFoundException，最终转成 404。但有些场景要更细粒度控制：比如跳转到创建页、返回 JSON 错误码、或记录日志后 fallback 到默认模型。
Route::model('user', \App\Models\User::class, function ($id) { throw new \App\Exceptions\CustomUserResolveException("ID {$id} is invalid"); });- 注意
Route::model()的第三个参数是“找不到时的回调”，而Route::bind()的闭包是“每次都要执行的解析逻辑”——二者用途不同，别混用 - 如果你只是想改异常类型，用
Route::model()更轻量；如果要改整个查询过程（加 join、加 where、换表），必须用Route::bind()
需要在路由组内局部覆盖绑定规则
全局注册的显式绑定是应用级的，但有时 API 和 Web 路由对同一参数有不同解析需求。比如 Web 端用 slug，API 端却要用 uuid。
- 不能在
RouteServiceProvider里写两个Route::bind('post', ...)，后注册的会覆盖前一个 - 解决方案：把绑定移到路由文件中，在
Route::middleware(...)->group(...)内部调用Route::bind()，它的作用域就是当前 group - 示例：
Route::bind('post', fn($v) => Post::where('uuid', $v)->firstOrFail());放在 API 路由组里，不影响 Web 组的slug绑定
真正容易被忽略的是作用域和优先级：显式绑定一旦注册，就会覆盖所有同名参数的隐式行为，包括资源路由生成的 {user}。如果你在 RouteServiceProvider 里绑定了 user，又在控制器里写了 function (User $user)，框架不会再去调用 User::resolveRouteBinding() —— 它只认你注册的那个闭包。这点调试起来很隐蔽，尤其是团队协作时有人悄悄加了全局 Route::bind() 却没同步文档。
