Laravel 6中间件依赖注入必须通过构造函数实现，服务容器自动解析类型提示的依赖类；handle方法仅接收$request、$next及路由参数，不支持依赖注入。
Laravel 6 的服务容器在中间件中使用依赖注入，核心是让框架自动解析并注入你声明的依赖类，而不是手动 new 实例。这不仅提升可测试性，也保持逻辑清晰、职责明确。
构造函数注入是最推荐的方式
中间件类的构造函数支持类型提示，Laravel 会通过服务容器自动解析并传入对应实例。
- 定义一个服务类，比如 AuthService，它封装了登录态检查逻辑
- 在中间件中声明构造函数参数：
public function __construct(AuthService $authService) - Laravel 自动完成实例化与注入，无需调用
$app->make()或app() - 后续在
handle()方法里直接使用$this->authService即可
注意 handle 方法不参与依赖解析
handle() 方法的前两个参数固定为 $request 和 Closure $next，其余参数（从第三个起）只接收路由中传入的字符串参数，不是依赖对象。
- 错误写法：
public function handle($request, Closure $next, AuthService $authService)—— 这会导致运行时解析失败 - 正确做法：所有服务类必须放在构造函数里注入；
handle只处理请求逻辑和路由参数（如role:admin中的admin）
需要绑定接口或自定义实例时，在服务提供者中注册
如果依赖的是接口（如 LoggerInterface），或构造函数含原始值（如 API key），需提前绑定。
- 在
AppServiceProvider@register()中添加：$this->app->singleton(AuthService::class, function ($app) {<br> return new AuthService($app['config']['auth.driver']);<br>}); - 这样容器才知道如何创建
AuthService，尤其当它本身也有依赖时
避免在中间件里手动解析
不要在 handle() 中写 app(AuthService::class) 或 resolve() —— 这绕过了容器的生命周期管理，也破坏了单例等行为预期。
- 手动解析会让单元测试变困难，因为无法轻松 mock 依赖
- 构造函数注入天然支持测试时传入模拟对象（Mock）
- 若真需动态决定服务，应把判断逻辑移到服务内部，而非中间件中临时拉取
