HTTP 入口解析

public/index.php 入口

在 public/index.php 中第 24 行

逻辑为，引入 ../vendor/autoload.php，即 composer 产生的 vendor/autoload.php。

接着第 38 行

这里面做的事情不少，具体的我们看 bootstrap/app.php 的代码。

bootstrap/app.php 实例化容器

在第 [14-16行]

这是 Laravel 框架内为数不多的直接 new 出来的对象，也就是框架的应用对象，
此对象继承于 Illuminate\Container\Container （容器），
所以， Laravel 框架中的容器对象一般就是指的 Illuminate\Foundation\Application 对象（因在实际运行过程中，不会直接 new Illuminate\Container\Container 的）。

在第 [29-42行]

这里的singleton是 public/index.php 中，用 Illuminate\Contracts\Http\Kernel 能注入后取出 App\Http\Kernel 的关键。

关于 singleton() 的解析，请见 10. 容器的 singleton 和 bind 的实现

第 55行

在前面 public/index.php 中的

public/index.php 构建 + 处理

在 public/index.php 第 52 行

这里调用了 Illuminate\Foundation\Application 的 make 方法（具体解析请见本篇结尾的链接），获得了 http 处理器 ( $kernel )

然后第 54-56 行

Request::capture 请求捕获

Illuminate\Http\Request::capture() 的代码为

其中调用了 Symfony\Component\HttpFoundation\Request::createFromGlobals()

(new static)->duplicate() 最终执行了

在后面的

作用是调用 $request->input() 之时

GET、HEAD 请求，能取到 GET 参数，
POST 请求，能取到 POST 参数。

至此，Request::capture() 就执行完了。

public/index.php 运行逻辑

然后交给 App\Http\Kernel 的 handle 方法进行处理，获得 $response (Illuminate\Http\Request 对象)。

Laravel 框架的设计绝大可扩展部分（如服务提供者、中间件）都是在这个阶段处理和触发的，
所以我单独把 02. HTTP Kernel Handle 解析 拆出去了。

最后，在第 58-60行

调用 Illuminate\Http\Response 的 send 方法，将响应的状态码/头/内容返回给客户端(浏览器)，具体过程可见本篇末尾的引用。

• Illuminate\Foundation\Application 的 singleton、bind 方法和 make 解析请见 10. 容器的 singleton 和 bind 的实现
• App\Http\Kernel 的 handle 方法解析请见 02. Kernel Handle解析
• App\Http\Kernel 的 terminate 方法解析请见 14. Response 对象和 Kernel::terminate

一图胜千言，如果配上图，是不是更好表达，您觉得了？

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 国际」创作共享协议，
转载前请阅读 相关说明 »

根据 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 方法

核心逻辑就这句：

还记得那个《高速修车》的陈年老梗吗：

公司的业务呢，就像跑在高速路上的车，车不能停，但是新需求和修bug也不能停。

这里要跟大家扒代码的 Macroable 呢，有点像上面这个悖论的出路；但其实也不是，因为他没有实现 修 且不停，只实现了 增 且不停。请原谅我这尴尬的幽默。

从陈年教程入手

网上很多教程都是提及了，Laravel 绝大部分类，都可以扩展方法。比如这个例子：

use Illuminate\Support\Collection;

Collection::macro('bcsum', function () {
    $sum = 0;
    foreach ($this as $item) {
        $sum = bcadd($sum, $item, 2);
    }
    return $sum;
});

dump((new Collection([1,2,3,4]))->bcsum()); // it says "10.00"

我们可以看到，在不改变代码的前提下，我们在使用的过程中给 Illuminate\Support\Collection 扩充了 bcsum 的功能。就如同在其中加入了如下代码：

<?php

class Collection ...
{
    public function bcsum()
    {
        $sum = 0;
        foreach ($this as $item) {
            $sum = bcadd($sum, $item, 2);
        }
        return $sum;
    }
}

代码解析

我们看到，Illuminate\Support\Collection 使用了 Illuminate\Support\Traits\Macroable 这个 trait。

macro 的代码

作用是将闭包存进static::$macros

魔术方法

在调用我们的方法时，按名字匹配出来，参数传入触发。

这里之所以定义了两个方法，__call 和 __callStatic，是因为 laravel 很多类，部分可以静态调用，部分可以动态调用。macroable 如果要能被这两种类可用，那么就需要定义两个魔术方法。

经验分享

失灵的情况

一. 魔术一个魔术方法，不可行

我们现在知道了 Macroable 的神奇，但是其实Macroable 也有失灵的时候。举个例子：

<?php
class JoeDoe
{
    use \Illuminate\Support\Traits\Macroable;
}

JoeDoe::macro('__toString', function () {
    return '123';
});

echo new JoeDoe();

而运行时，其还是报了这个错：

PHP Recoverable fatal error:  Object of class JoeDoe could not be converted to string

但是如果我们在 JoeDoe 这个类中手工硬编码 __toString 这个方法却是可以运行的的；
为什么？

其实道理很简单，因为 echo JoeDoe 对象时候，php 内核检查其中有没有 __toString 这个方法时，就已经报错了，根本还来不及走到 __call 这个魔术方法。

总结: Facade 就是一个标记便捷的调用容器盛放对象的方法的设计。

一般的，Facade 类都继承于 Illuminate\Support\Facades\Facade。

比如 Illuminate\Support\Facades\Gate 这个门面：

<?php
namespace Illuminate\Support\Facades;

use Illuminate\Contracts\Auth\Access\Gate as GateContract;

class Gate extends Facade
{
    /**
     * Get the registered name of the component.
     *
     * @return string
     */
    protected static function getFacadeAccessor()
    {
        return GateContract::class;
    }
}

代码中我们只需要留意 getFacadeAccessor 方法是在 Illuminate\Support\Facades\Gate 中定义的就好了。
我们来分析 Illuminate\Support\Facades\Facade：

魔术方法 part 1

首先我们来看末尾的 __callStatic 方法：

还记得 Facade 类我们是怎么调用的吗？

静态调用！比如 Gate::allows() 。

因为在 Facade 类中定义了 __callStatic 魔术方法，所以只要静态调用了里面没有提供的方法，都会走到魔术方法里面。
这个魔术方法内部有一个取出实例的逻辑：

$instance = static::getFacadeRoot();

代码位于

前面，我们留意了 static::getFacadeAccessor() 是位于 Illuminate\Support\Facades\Gate 中的，而 static::getFacadeAccessor() 运行后作为参数给了 static::resolveFacadeInstance()，后者实现为

而 static::$app 就是容器对象

这句

就是从容器取出对象。

总结 getFacadeRoot 的逻辑大概为

1. 判断 static::getFacadeAccessor() 返回是否对象，如果对象则直接使用。
2. 在 Facade::$resolvedInstance 数组中尝试根据 $name 取出对象，避免多次调用时，每次都取。
3. 从 Illuminate\Foundation\Application 容器取出对象。

魔术方法 part 2

拿到 $instance 后，先验证 $instance 是否为空。如果是就报错 A facade root has not been set.。

所以如果遇到 A facade root has not been set. 这个错误，一般都是 a. 相应的服务提供者未注册； b. 对象绑定到容器的别名跟 static::getFacadeAccessor() 返回不一致。

最后，直接把方法和参数穿透到背后的 $instance 去执行。

Laravel 有很多 facade 门面，背后穿透的不只一个类(譬如 DB、 View、Session)，这是怎么回事呢？
请看 15. Laravel 神奇的 Manager 类

Kernel Handle

App\Http\Kernel 继承自 Illuminate\Foundation\Http\Kernel 类，所以本文章的分析主要集中在 app/Http/Kernel.php 和 vendor/laravel/framework/src/Illuminate/Foundation/Http/Kernel.php 两个类中

__construct 解析

因为 App\Http\Kernel 没有 __construct 方法，所以穿透到了 Illuminate\Foundation\Http\Kernel 的 __construct：

首先是此方法传入参数的 __construct(Application $app, Router $router) 声明，这里恰好使用了 Laravel 容器的依赖注入(Dependency Injection，Inversion of Control的一种)设计。具体的在本篇不讲述，可参见本篇末尾的单独分析的链接的文章。

执行到 __construct 时， Illuminate\Foundation\Application 容器会将 Illuminate\Foundation\Application（即应用容器自身）和 Illuminate\Routing\Router 注入到方法内。然后逻辑代码将两个对象赋给 App\Http\Kernel 的 $this 属性中。

然后将 Illuminate\Foundation\Http\Kernel 的 $middlewarePriority 属性

根据其注释，此属性是强制对 middleward 中间件执行顺序进行排序的作用。

在后面将 App\Http\Kernel 中声明的 $middlewareGroup

紧接着，将

至此， Kernel::__construct() 解析完毕。

handle 解析

Illuminate\Http\Request 继承自 Symfony\Component\HttpFoundation\Request
并且 Illuminate\Http\Request 未覆盖 enableHttpMethodParameterOverride

然后，调用 Illuminate\Foundation\Http\Kernel 的 sendRequestThroughRouter

通过第142行，将 $request 注入进 Illuminate\Foundation\Application 容器。

144行，将门面类中的 request 数据清理掉

Bootstrap 解析

然后146行，调用 Illuminate\Foundation\Http\Kernel 的 bootstrap 方法

第161执行到容器的 hasBeenBootstrapped 方法

第162实际得到这个数组

特别留意206行的 make 调用

关于容器 make 方法的细节
请查阅 10. 容器的 singleton 和 bind 的实现 的 “揭开 Container::make() 神秘的面纱” 段落

然后结果就是依次执行

• \Illuminate\Foundation\Bootstrap\LoadEnvironmentVariables
• \Illuminate\Foundation\Bootstrap\LoadConfiguration
• \Illuminate\Foundation\Bootstrap\HandleExceptions
• \Illuminate\Foundation\Bootstrap\RegisterFacades
• \Illuminate\Foundation\Bootstrap\RegisterProviders
• \Illuminate\Foundation\Bootstrap\BootProviders

这些 Bootstrap 类的 bootstrap 方法

上面列出的清单中，分别作用为

其中最后两项在 laravel 请求的生命周期中是至关重要的，我们将在后续文章中重点讲解。

在 bootstrap 阶段结束后，Kernel::sendRequestThroughRouter 后面带 pipeline 关键字的代码就是管道。

关于管道请查阅 05. Pipeline 解析

在进入管道前， 调用了 dispatchToRouter 返回一个闭包对象

匹配路由的逻辑清晰可见

如果一路抽丝剥茧，我们便能找到 Router 调用 controller 的逻辑了。 请见06. RouteServiceProvider 详解 最后段落。

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

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

定义

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

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

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

解析反射

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

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

第一步 解析参数

resolveClassMethodDependencies 的实现