根据 Laravel 的 Events 文档 (中文版：事件系统)， EventServiceProvider 的使用方法为：

/**
 * 注册应用中的其它事件。
 *
 * @return void
 */
public function boot()
{
    parent::boot();

    Event::listen('event.name', function ($foo, $bar) {
        //
    });
}

如果花点时间研究 Event 这个 Facade，我们可以找到他穿透类其实为 Illuminate\Events\Dispatcher。

Illuminate\Events\Dispatcher 类的 __construct 方法为：

作用是将容器设置到 $this->container 属性

监听

我们刚刚在 EventServiceProvider 调用的 Event::listen 方法的代码为：

如果监听了通配事件，setupWildcardListen 在辗转后跟 else 一样的调用到了 makeListener

注意，返回的是闭包！并不会立即执行。

在存放到 $this->listeners 后，事件们就静静地等待被触发

触发

在我们调用 event() 辅助方法后，触发的逻辑其实走到了 dispatch 方法

核心逻辑就这句：

Laravel 提供了完善的用户状态判断鉴定、验证机制，这篇文章我们用十五分钟左右的时间来深入框架内部来了解它。
在学习之前，建议先查阅 Laravel China 文档库 > Laravel 5.7 > 用户认证，熟悉用法后，学习效率更高。

相关类

配置文件解析

Auth::guard 可用的守护者定义在：

这些配置文件中的 providers 定义在

而

session 和 token 分别指的是 Illuminate\Auth\SessionGuard 和 Illuminate\Auth\TokenGuard。

具体的构建方法见 AuthManager::createSessionDriver 和 AuthManager::createTokenDriver，这两个方法是在 AuthManager::resolve 时用以下代码调用的。

laravel/vendor/laravel/framework/src/Illuminate/Auth/AuthManager.php

Line 91 in 4d76a68

$driverMethod = 'create'.ucfirst($config['driver']).'Driver';

注册流程 基础 + 容器部分

Illuminate\Auth\AuthManager 类

• public createUserProvider($provider = null): Illuminate\Contracts\Auth\UserProvider|null
• protected getProviderConfiguration($provider): array|null
• protected createDatabaseProvider($config): Illuminate\Auth\DatabaseUserProvider
• protected createEloquentProvider($config): Illuminate\Auth\EloquentUserProvider
• public getDefaultUserProvider(): string

在 Illuminate\Foundation\Application 的 registerCoreContainerAliases 方法中，注册 auth 时， Illuminate\Auth\AuthManager 被使用。

注册流程 服务提供者 Illuminate\Auth\AuthServiceProvider

在 Illuminate\Auth\AuthServiceProvider 中的 register 方法，

registerAuthenticator 方法为

registerUserResolver 方法为

这里便将 auth 和 Illuminate\Contracts\Auth\Authenticatable 成功的从 Application 中的 alias 升级为 singleton 。

在我们的 config/app.php 的 providers 第一个便是 Illuminate\Auth\AuthServiceProvider

到这里，web 环境框架启动部分所有初始化用户状态维护机制就完成。

中间件流程 限制登陆后可访问

当一个路由声明必须登陆后可访问，也就是 auth 中间件，会触发：

在容器构建 AuthManager 时，会触发 __construct

中间件的 handle

调用了中间件 authenticate 方法

如果没登陆，报错

获取当前用户流程

如果手工在业务中使用 auth()->user() 会触发

AuthManager 的 guard() 默认返回的是 SessionGuard，所以 auth()->user() 调用的是

其 131 行的 $this->provider->retrieveById($id) 调用了 EloquentUserProvider::retrieveById

$this->createModel() 返回的是 $this->model，是在

在 AuthManager 调用 createUserProvider 后调用 createEloquentProvider 方法时，

其传进去的 $config 的获取逻辑为

也就是这里设定的 'model' => App\User::class 了

前面 getAuthIdentifierName 的方法，就是调用 App\User::getAuthIdentifierName 来查找用户了。

本文章采用「署名 4.0 国际」创作共享协议，
转载前请阅读 相关说明 »

在前面 01. HTTP 入口解析 的第 54-56 行代码分析时

我们只分析了 $request 的产生，却没有分析 $response 。
这节，我们就来研究下 Laravel 的 Response 对象: Illuminate\Http\Response。

Illuminate\Http\Response 初识

不难看出，这句代码拿到的一定是个对象。为什么？
因为在下文，就调用了他的 ->send() 方法。

那么 Illuminate\Http\Response 对象是从哪里来的呢？

在从 入口 到 Kernel::handle() 到 管道 的过程尾声，我们拿到了这句逻辑

这个 prepareResponse 是干嘛的呢？

调用了

过程为：

• 判断是否为 PsrResponseInterface 对象；
• 则判断为模型，且刚创建，将响应头 statusCoe 强制覆盖成 HTTP 201 created ；
• 否则判断返回的对象是否具有序列号特征，如果是就重置成 JsonResponse；
• 否则的话覆盖成 Response；

于是乎，我们才可以在 controller 中大胆的直接返回字符串而转换成 Response 对象。因为在这里他帮我们转了。

经过上面这一波加工后，在 public/index.php 里面才敢执行 $response->send()

Illuminate\Http\Response::send() 的逻辑

调用的 sendContent 逻辑为

先于 sendContent 的 sendHeaders 的代码要稍微复杂一点

先是将 http 响应头依次输出，然后将 Cookie 处理后输出。

在 send 方法的后面，还有几句

至此，send 逻辑就讲完了。

Kernel::terminate() 的逻辑

App\Http\Kernel 并没有 terminate 方法，一路穿透到了 Illuminate\Foundation\Http\Kernel 里面

Illuminate\Foundation\Http\Kernel::terminateMiddleware() 逻辑

而这句就比较好理解了，直接调用了容器的 terminate()

容器的 terminate() 方法也比较简单，触发 $terminatingCallbacks 注册的回调。

PHP的不常驻特性，一个请求完了就自动回收资源，那么除了需要触发 $terminatingCallbacks 回调外，为什么还要实现 terminate() 呢？

Laravel 为我们提供了一个 php artisan serve 的便捷服务器，启动后 Application 对象是常驻的。所以需要单独回收需要回收的资源。

php artisan serve 的本质也是 php -S，详细资料 PHP 的命令行模式>内置Web Server。

扩展阅读：在 Laravel 5.3 以前，Kernel::terminate() 还调用了 fastcgi_finish_request()。后来移除了，主要原因是因为这个函数会阻断 http 响应的头和 body，造成部分特殊情况的 session 问题，不过也可能还有其他原因。

本章节以前面没有分析完成的 02. HTTP Kernel Handle 解析 和 06. RouteServiceProvider 详解 做铺垫，通过讲述其最后 runController 的内部逻辑，抛砖引玉，分析 Laravel 依赖注入的原理，

因为前面我们讲了容器对象的绑定的实现 (见：10. 容器的 singleton 和 bind 的实现)，所以在这里不再详述。

定义

在大型项目中，因为类的繁多，彼此需要调用到的代码的更多，如果我们在用到对象的每一个地方去 new FooClass(... $parameters )，那么我们的项目重复代码太多，早晚会失去优雅性和可维护性。

所以依赖注入就是在用到一个对象的方法入参声明，你要什么对象，他基于什么实现。框架 (亦或独立的 容器服务 )在执行到这里的时候，发现你声明了需要那几个对象，在 容器服务 里找到这几个对象的实例化逻辑，实例化出来扔进去执行。

路由执行中的依赖注入的实现

解析反射

这里的 Route 对象本身已经是单个路由了，所以 $this->getController() 和 $this->getControllerMethod() 取得的具体的 Controller 类名和方法名。

核心代码其实就是这个 $this->controllerDispatcher()->dispatch() 方法了

第一步 解析参数

resolveClassMethodDependencies 的实现

其中

为什么没报错，是考虑到 controller 也是可以用 __call 魔术方法来绑定路由的。

resolveMethodDependencies 的逻辑就是将传入的反射对象的入参解析完成

容器挂靠

紧接前文代码

[划重点，前方高能]
如果此参数为一个类，且不是路由中出现的参数，返回 默认值（如有），否则从容器创建

路由的执行

dispatch 方法的下半段

如果控制器定义了 callAction，执行。
接着直接调用 controller 的方法。

鉴权

在 config/app.php 中我们能看到 Illuminate\Broadcasting\BroadcastServiceProvider 这个服务提供者被注册：

第17行调用到了 Illuminate\Support\Facades\Broadcast::routes() 假面方法。

顾名思义，就是注册路由的。而这个方法，最终是穿透到了 Illuminate\Broadcasting\BroadcastManager::routes()

第19行是为了在 config/app.php 卸载 BroadcastServiceProvider 时，直观的让 routes/channels.php 失效的做法，所以就不放在别处

第61~63行是如果缓存过路由，则跳出。

第62~第72行相当于与执行了

Route::group(['middleware' => ['web']], function () {
    Route::match(['get', 'post'], '/broadcasting/auth', '\\'.BroadcastController::class.'@authenticate');
});

方法调用到的 controller action 其实是

这个假面方法 Broadcast::auth() 比较特殊，是根据 config('broadcasting.default') 分发到 Illuminate/Broadcasting/Broadcasters 具体的类中：

• LogBroadcaster.php
• NullBroadcaster.php
• PusherBroadcaster.php
• RedisBroadcaster.php

我们以 redis 的配置为例 (laravel-echo-server) 。

第一步，如果 $request->channel_name 不以 private- 或者 presence- 开头，或者没有提供用户授权导致请求取不到用户，抛出 Symfony\Component\HttpKernel\Exception\AccessDeniedHttpException 异常

第二步，将 $request->channel_name 中的 private- 或者 presence- 还原移除。

第三步，调用 Broadcaster:: verifyUserCanAccessChannel()

将 routes/channels.php 中定义的 channel_name 匹配上的通道的鉴权回调执行，拿到返回值。如果 if ($result = $handler($request->user(), ...$parameters)) 返回成功的 RedisBroadcaster::validAuthenticationResponse()，否则抛出 Symfony\Component\HttpKernel\Exception\AccessDeniedHttpException 异常

而成功的响应 RedisBroadcaster::validAuthenticationResponse() 逻辑为返回 user_id 和 user_info 给 websocket 客户端：

至此，鉴权部分完成。

推送

broadcast() 方法定义于

此方法最终走到了

PendingBroadcast 类比较特殊，有个 __destruct 解构方法：

走到

调用了

还是回到了 BroadcastManager

第127~129行，是将广播事件 BroadcastEvent 入队。

根据我们对队列的了解，BroadcastEvent 应该有 handle() 方法

第46~49行，是执行广播，调用了 RedisBroadcaster::broadcast()

消息进入 redis。

// TODO: laravel-echo-server 部分。

RouteServiceProvider 详解

在 RouteServiceProvider::boot 阶段，所有路由都只是执行登记，匹配的逻辑是在 02. HTTP Kernel Handle解析 的 dispatchToRouter 阶段。

我们先找到 RouteServiceProvider.php

在 config/app.php 的 providers 中定义的 RouteServiceProvider 其实是:

我们分析 Illuminate\Foundation\Support\Providers\RouteServiceProvider 的代码

register() 阶段

其 register 方法是空的

boot() 阶段

而在 boot 阶段，几乎运行了 RouteServiceProvider 中的所有方法

一. setRootControllerNamespace()

二. 判断路由是否缓存过

Illuminate\Foundation\Application::routesAreCached，
其实就是判断文件 bootstrap/cache/routes.php 是否存在

三. 如果没有缓存，则遍历路由