laravel5.5源码笔记（一、入口应用的初始化）

laravel的项目入口文件index.php如下

define('LARAVEL_START', microtime(true));

require __DIR__.'/../vendor/autoload.php';

$app = require_once __DIR__.'/../bootstrap/app.php';

$kernel = $app->make(IlluminateContractsHttpKernel::class);

$response = $kernel->handle(
    $request = IlluminateHttpRequest::capture()
);

$response->send();

$kernel->terminate($request, $response);

第一句记录了项目开始运行时间。

第二句引入了基于composer的自动加载模块。

第三句引入了laravel应用主体。

第四句创建了一个用于处理请求的核心。

第五句对实例化后的request对象进行解析并返回执行后的response响应对象。

第六句将响应内容进行输出。

第七句结束应用并释放资源。

关于第二句，这里我先解释一下自动加载，我们都知道php中如果要使用文件外的代码，需要使用require等方法先将文件引入，然后就可以使用被引入那个文件的代码了。但是我们平时使用框架编写代码的时候就不需要这么做了，只需要use命名空间，便可以直接new出对象了，这就要归功于自动加载了，php在new出当前不存在的对象时，会触发__autoload、spl_autoload等一些魔术方法。tp3的处理方式遍是非常粗暴的，在autoload魔术方法中，将当前类use的命名空间与我们new的对象名进行字符串拼接，随后require该文件就完了。laravel使用了composer显然就高级的多，不过再怎么高级，composer本身也是做了类似的操作，所以它也使用了spl_autoload函数，它高级在哪呢？我们都知道composer使用时可以新建一个json文件将需要的依赖编写在里面，composer运行时就会自动下载这些文件了。用composer 做自动加载也是一样，它将json文件里写入的依赖进行缓存成了key/value的关联数组，触发spl_autoload函数的时候便根据这些映射来require。存放在laravelvendorcomposerautoload_classmap.php文件内，有兴趣的朋友可自行观看，这里不是重点，便到此为止了。(我初学php面向对象的时候一直以为命名空间下面那些use就是用来替代require、include的。直到后来学习mvc概念的时候自己试着做了个微框架的demo，才搞清楚use只是起到明确命名空间的作用。)

我们都知道，通常一个web程序所做的事，不外乎这么几点：

1、用户从浏览器进行请求，请求

2、程序接到请求开始运算，网页程序

3、运算结果渲染成网页返回给浏览器，网页响应

我们所写的大量代码都只是为了更好、更快、更方便的去做这3件事而已。

index文件中的$request、$kernel、$response这三个变量就分别与这三点进行对应了。laravel中也将请求、响应、和计算进行了分离，请求部分使用syfmony的request组件对浏览器发出的请求头等信息进行收集打包，形成一个对象来方便我们操作。$kernel算是laravel的请求处理核心了，通过request里的url找到相应路由的控制器，执行后返回视图等响应，并将$response输出至浏览器。知道大概流程后我们来看laravel的核心部分。

第三句代码就是在引入laravel的应用了，我们跳到G:wamp64www estlaravel55ootstrapapp.php文件内，我们会发现这个文件所做的事情也不多，只是new了一个application对象，调用了三次singleton方法，便将application实例给返回到index文件中了。(而这里new对象的时候整个文件都没有写require等代码，这就是通过composer进行的自动加载起作用了。)application文件位于G:wamp64www estlaravel55vendorlaravelframeworksrcIlluminateFoundationApplication.php，new application时传入了当前的路径到它的构造方法里，它的构造方法执行了setBasePath、registerBaseBindings、registerBaseServiceProviders、registerCoreContainerAliases这几个方法。

setBasePath：就是将各个系统关键类的路径存储在了app容器对象里，跟踪到bindPathsInContainer方法里，我们会发现如下所示的，存储的路径，具体的实现代码在其父类Container类的instance方法中，代码很简单就一句是$this->instances[$abstract] = $instance;。大家可以在Application类的setBasePath方法之后使用dd()打印一下$this看看它的instance属性

    protected function bindPathsInContainer()
    {
        $this->instance('path', $this->path());
        $this->instance('path.base', $this->basePath());
        $this->instance('path.lang', $this->langPath());
        $this->instance('path.config', $this->configPath());
        $this->instance('path.public', $this->publicPath());
        $this->instance('path.storage', $this->storagePath());
        $this->instance('path.database', $this->databasePath());
        $this->instance('path.resources', $this->resourcePath());
        $this->instance('path.bootstrap', $this->bootstrapPath());
    }

registerBaseBindings：这个方法做的事情和上一个差不多，将$this，application对象及它的父类存入了instance属性中，分别起了app和Container两个名字。将vendor路径与bootstrap/cache/packages.php里的providers服务提供者路径传入PackageManifest类中，并绑定在了app对象的instance中，大家在这个方法后dd($this)会发现跟setBasePath一样，instance属性中多了几条，只是其中三个是对象而已。

registerBaseServiceProviders：注册了基本的providers，event事件服务提供者、log日志服务提供者、routing路由部分服务提供者。服务提供者的部分会在后面解释，现在把它看做是一个功能模块的入口就可以了。同样的，我们在这个方法后面dd($this)会发先serviceProviders属性与loadedProviders属性增加了对应的值。bindings属性也增加了provider相应的boot闭包，闭包中存储的是实例化对象的代码，运行后会得到一个对象实例，以闭包的形式存储来实现按需加载。

registerCoreContainerAliases：跟它的名字说的一样，只是注册了容器的核心类别名，同样打印后发现在aliases、abstractAliases属性中增加了相应的映射数组。以后会根据这个别名来方便的实例化对象，这个列表太长我就不放图了

好的，总结一下，application类初始化的时候它做了这么些工作：

1、设置路径  2、绑定了app对象和packages包的实例 3、注册了基本服务提供者 4、增加了核心类的别名  全都是一些配置工作。

好，回到app.php文件，$app执行了三个singleton方法，通过注释我们可以知道它绑定了一些重要的接口道容器中。我们点击跳转后一路跟踪到G:wamp64www estlaravel55vendorlaravelframeworksrcIlluminateContainerContainer.php文件的bind方法中看着很长的代码，其实都是状态判断，这个函数所做的事情还是讲传入的类名路径转换为一个启动服务的闭包，并保存在容器的bindings属性中。见下方代码，getClosure方法也可以看一下，比较简单。

    public function bind($abstract, $concrete = null, $shared = false)
    {
        //抽象类型判断
        $this->dropStaleInstances($abstract);

        if (is_null($concrete)) {
            $concrete = $abstract;
        }

        //这一阶段重点，刚刚我们index传入的类路径不是闭包，就会在这里被getClosure方法转换成一个返回对象实例的闭包了
        if (! $concrete instanceof Closure) {
            $concrete = $this->getClosure($abstract, $concrete);
        }
        //将闭包绑定在bindings属性中
        $this->bindings[$abstract] = compact('concrete', 'shared');

        // If the abstract type was already resolved in this container we'll fire the
        // rebound listener so that any objects which have already gotten resolved
        // can have their copy of the object updated via the listener callbacks.
        if ($this->resolved($abstract)) {
            $this->rebound($abstract);
        }
    }    

我们在app.php文件的singleton之后再次dd($app)会发现bindings属性中多出了几个相应的属性，见下图，其中httpkernel用来处理http请求，consolekernel用来处理artisan命令行请求，debugexceptionHandler便是处理异常错误的了。

 app.php文件看完了，我们再回到index.php文件，第四行laravel制造了一个kernel实例，还记得刚刚在app.php文件时，我们通过singleton绑定的那个闭包函数吗？这里马上就派上用场了，make顾名思义就制造，这个方法通过类名路径或别名返回一个对象实例(对，还记得刚刚application对象构造函数绑定了一大堆别名吗)。G:wamp64www estlaravel55vendorlaravelframeworksrcIlluminateFoundationApplication.php类的make方法

    public function make($abstract, array $parameters = [])
    {
        //这里获取了传入类的别名，getAlias方法通过递归取出存储在容器中的别名，不过现在kernel没有别名所以还是刚刚传入的类路径
        $abstract = $this->getAlias($abstract);
        //也不是延迟加载服务直接跳转到父类make方法
        if (isset($this->deferredServices[$abstract]) && ! isset($this->instances[$abstract])) {
            $this->loadDeferredProvider($abstract);
        }

        return parent::make($abstract, $parameters);
    }

 G:wamp64www estlaravel55vendorlaravelframeworksrcIlluminateContainerContainer.php在container类的make方法就开始从容器中解析类了，一开始那一大段都是检测上下文绑定的，这个属于契约接口的动态调用，暂时可以不去看它，重点在于从getConcrete方法获取到闭包后，直接进入了build构建方法。

    public function make($abstract, array $parameters = [])
    {
        return $this->resolve($abstract, $parameters);
    }

    protected function resolve($abstract, $parameters = [])
    {
        $abstract = $this->getAlias($abstract);
        //是否存在构建上下文，此出为了服务提供者的契约
        $needsContextualBuild = ! empty($parameters) || ! is_null(
            $this->getContextualConcrete($abstract)
        );

        // If an instance of the type is currently being managed as a singleton we'll
        // just return an existing instance instead of instantiating new instances
        // so the developer can keep using the same objects instance every time.
        //instances数组中有该类，并且不需要构建上下文的话，便直接返回该类实例
        if (isset($this->instances[$abstract]) && ! $needsContextualBuild) {
            return $this->instances[$abstract];
        }
        //将实例化类所需的参数存入数组
        $this->with[] = $parameters;
        //获取该类闭包，若无则还是返回类名字符串
        $concrete = $this->getConcrete($abstract);

        // We're ready to instantiate an instance of the concrete type registered for
        // the binding. This will instantiate the types, as well as resolve any of
        // its "nested" dependencies recursively until all have gotten resolved.
        //若当前所make的类没有上下文绑定，并且是一个闭包则直接进行构建，否则再次递归make方法获得契约所绑定类
        if ($this->isBuildable($concrete, $abstract)) {
            $object = $this->build($concrete);
        } else {
            $object = $this->make($concrete);
        }

        // If we defined any extenders for this type, we'll need to spin through them
        // and apply them to the object being built. This allows for the extension
        // of services, such as changing configuration or decorating the object.
        foreach ($this->getExtenders($abstract) as $extender) {
            $object = $extender($object, $this);
        }

        // If the requested type is registered as a singleton we'll want to cache off
        // the instances in "memory" so we can return it later without creating an
        // entirely new instance of an object on each subsequent request for it.
        //若该类绑定时设置为共享，则缓存至instances单例数组
        if ($this->isShared($abstract) && ! $needsContextualBuild) {
            $this->instances[$abstract] = $object;
        }

        $this->fireResolvingCallbacks($abstract, $object);

        // Before returning, we will also set the resolved flag to "true" and pop off
        // the parameter overrides for this build. After those two things are done
        // we will be ready to return back the fully constructed class instance.
        $this->resolved[$abstract] = true;

        array_pop($this->with);

        return $object;
    }

还记得刚刚在app.php文件中有一个singleton函数将IlluminateContractsHttpKernel::class绑定为了AppHttpKernel::class类吗？当build方法执行到kernel的构造函数时，跳转到其父类G:wamp64www estlaravel55vendorlaravelframeworksrcIlluminateFoundationHttpKernel.php看一看

    public function build($concrete)
    {
        // If the concrete type is actually a Closure, we will just execute it and
        // hand back the results of the functions, which allows functions to be
        // used as resolvers for more fine-tuned resolution of these objects.
        //若传入的是一个闭包则直接通过闭包实例化类，这种闭包一般由provider类在laravel应用初始化阶段通过bind方法进行绑定。
        if ($concrete instanceof Closure) {
            return $concrete($this, $this->getLastParameterOverride());
        }
        //制造一个类反射
        $reflector = new ReflectionClass($concrete);

        // If the type is not instantiable, the developer is attempting to resolve
        // an abstract type such as an Interface of Abstract Class and there is
        // no binding registered for the abstractions so we need to bail out.
        if (! $reflector->isInstantiable()) {
            return $this->notInstantiable($concrete);
        }
        //将当前所实例化的类存入栈
        $this->buildStack[] = $concrete;
        //获得该类构造方法
        $constructor = $reflector->getConstructor();

        // If there are no constructors, that means there are no dependencies then
        // we can just resolve the instances of the objects right away, without
        // resolving any other types or dependencies out of these containers.
        //构造函数没有参数则直接实例化
        if (is_null($constructor)) {
            array_pop($this->buildStack);

            return new $concrete;
        }
        //若有构造函数则获取其参数
        $dependencies = $constructor->getParameters();

        // Once we have all the constructor's parameters we can create each of the
        // dependency instances and then use the reflection instances to make a
        // new instance of this class, injecting the created dependencies in.
        //运行构造函数，并解决依赖
        $instances = $this->resolveDependencies(
            $dependencies
        );
        //解决完依赖，出栈
        array_pop($this->buildStack);

        return $reflector->newInstanceArgs($instances);
    }

    use IlluminateRoutingRouter;

    public function __construct(Application $app, Router $router)
    {
        $this->app = $app;
        //路由类实例，由容器自动加载依赖而来
        $this->router = $router;
        //系统中间件
        $router->middlewarePriority = $this->middlewarePriority;
        //中间件分组
        foreach ($this->middlewareGroups as $key => $middleware) {
            $router->middlewareGroup($key, $middleware);
        }
        //注册中间件别名
        foreach ($this->routeMiddleware as $key => $middleware) {
            $router->aliasMiddleware($key, $middleware);
        }
    }

可以看到，laravel在实例化出kernel对象的同时，通过kernel的构造函数加载了系统中间件，依赖了application与route两个对象。并将自身的$middlewareGroups、routeMiddleware数组解析进了route对象里，在路由进行调用的时候就会把路由方法上绑定的中间件名在这里解析出实例来调用了，其中routeMiddleware为别名所用。，随后在index.php文件中马上就利用kernel的handle方法，传入了一个request对象，来处理这次的网页url请求。

    public function handle($request)
    {
        try {
            //启用http方法覆盖参数
            $request->enableHttpMethodParameterOverride();
            //通过路由发送请求
            $response = $this->sendRequestThroughRouter($request);
        } catch (Exception $e) {
            $this->reportException($e);

            $response = $this->renderException($request, $e);
        } catch (Throwable $e) {
            $this->reportException($e = new FatalThrowableError($e));

            $response = $this->renderException($request, $e);
        }

        $this->app['events']->dispatch(
            new EventsRequestHandled($request, $response)
        );

        return $response;
    }

    protected function sendRequestThroughRouter($request)
    {
        //将请求存入容器
        $this->app->instance('request', $request);
        //清除facade门面
        Facade::clearResolvedInstance('request');
        //初始化引导
        $this->bootstrap();
        //让请求进入中间件
        return (new Pipeline($this->app))
                    ->send($request)
                    ->through($this->app->shouldSkipMiddleware() ? [] : $this->middleware)
                    ->then($this->dispatchToRouter());
    }
    //引导数组
    protected $bootstrappers = [
        IlluminateFoundationBootstrapLoadEnvironmentVariables::class,
        IlluminateFoundationBootstrapLoadConfiguration::class,
        IlluminateFoundationBootstrapHandleExceptions::class,
        IlluminateFoundationBootstrapRegisterFacades::class,
        IlluminateFoundationBootstrapRegisterProviders::class,
        IlluminateFoundationBootstrapBootProviders::class,
    ];

上面bootstrap中会分别执行每一个bootstrapper的bootstrap方法来引导启动应用程序的各个部分
1. DetectEnvironment 检查环境
2. LoadConfiguration 加载应用配置
3. ConfigureLogging 配置日至
4. HandleException 注册异常处理的Handler
5. RegisterFacades 注册Facades
6. RegisterProviders 注册Providers
7. BootProviders 启动Providers

启动应用程序的最后两步就是注册服务提供者和启动提供者，先来看注册服务提供器，服务提供器的注册由类IlluminateFoundationBootstrapRegisterProviders::class负责，该类用于加载所有服务提供器的 register 函数，并保存延迟加载的服务的信息，以便实现延迟加载。

所有服务提供器都在配置文件 app.php 文件的 providers 数组中。类 ProviderRepository 负责所有的服务加载功能：
loadManifest()会加载服务提供器缓存文件services.php，如果框架是第一次启动时没有这个文件的，或者是缓存文件中的providers数组项与config/app.php里的providers数组项不一致都会编译生成services.php。

application的registerConfiguredProviders()方法对服务提供者进行了注册，通过框架的文件系统收集了配置文件中的各种provicers并转化成数组，在G:wamp64www estlaravel55vendorlaravelframeworksrcIlluminateFoundationProviderRepository.php类的load方法中进行加载，但最终还是会在application类中的register()方法中通过字符串的方式new出对象，在执行provider中自带的register()方法

太多支线的细节不用深挖，重点在于让请求进入中间件这里，它用了一个管道模式，或者说装饰模式，通过函数调用栈的形式，对请求进行过滤（这个等到后面中间件的时候单独说）最终通过了所有中间件的请求会进入到IlluminateRouting outer类的dispatchToRoute方法

router类里的runRouteWithinStack方法通过管道的方式，运行了系统自带中间件。这些中间件里有一个laravelframeworksrcIlluminateRoutingMiddlewareSubstituteBindings.php中间件，用于处理路由上的绑定。其中调用了IlluminateRouting outer类中的substituteImplicitBindings方法对路由上的模型进行了绑定。在IlluminateRoutingRouteSignatureParameters.php中通过对路由route中的控制器字符串，或闭包函数，进行反射，获取到他们的参数名，与类型提示，并过滤出IlluminateContractsRoutingUrlRoutable类的子类，过滤后得到的便是模型的类型提示了。之后又在IlluminateRoutingImplicitRouteBinding.php类中通过容器的make方法将反射得到的类名实例化为对象，使用model中的resolveRouteBinding方法通过路由参数获取数据对象，而后在route类中赋值给route属性。IlluminateRoutingRoute类的runCallable方法里对路由进行了调用。控制器和方法是从路由文件中获取到的(通过symfony的request对象获取到pathinfo)，依然是通过字符串解析为类名和方法名，随后通过ioc容器实例化类为对象，再调用控制器基类的某个方法执行传入的方法名

IlluminateRoutingControllerDispatcher类的dispatch方法为真正执行的部分，其中resolveClassMethodDependencies方法会对控制器的参数实行依赖注入。传入从路由中获取的参数，与从控制器反射中获取的方法参数。如果该方法所需的参数不是一个模型绑定，则会通过容器中的make方法获取对象实例。

    public function dispatch(Route $route, $controller, $method)
    {
        //解析类方法的依赖
        $parameters = $this->resolveClassMethodDependencies(
            $route->parametersWithoutNulls(), $controller, $method
        );
        //若控制器中存在回调
        if (method_exists($controller, 'callAction')) {
            return $controller->callAction($method, $parameters);
        }
        //调用控制器方法
        return $controller->{$method}(...array_values($parameters));
    }

最后，控制器返回执行后的结果，被response类包装成响应对象返回至index.php，通过send方法发送至浏览器。