Bruce Lam
Bruce Lam
> Laravel 的管道机制，是其中间件 (middleware) 得以被序列执行的基础 # 管道机制 在开始之前我们先帖一段管理的应用代码，位于 [02. HTTP Kernel Handle解析](https://github.com/xiaohuilam/laravel/issues/2#L148) https://github.com/xiaohuilam/laravel/blob/d081c918b7e582ec5b3f94316f44834466cec37d/vendor/laravel/framework/src/Illuminate/Foundation/Http/Kernel.php#L148-L151 语义化得出的分析为 携带 `send` 请求对象，经过中间件的处理，然后进入路由。 ## 代码解析 1. send 携带方法 https://github.com/xiaohuilam/laravel/blob/d081c918b7e582ec5b3f94316f44834466cec37d/vendor/laravel/framework/src/Illuminate/Pipeline/Pipeline.php#L53-L64 好像没啥出奇的，就是传入并储存一个对象，返回 `$this` 2. through 经过方法 https://github.com/xiaohuilam/laravel/blob/d081c918b7e582ec5b3f94316f44834466cec37d/vendor/laravel/framework/src/Illuminate/Pipeline/Pipeline.php#L66-L77 好像也没啥关键的实现，传入“被管道”的集合，返回...
# ServiceProvider Register 解析 > 前面 [《02. Kernel Handle解析》](https://github.com/xiaohuilam/laravel/issues/2) 结尾，我们留下了 `注册服务提供者` 和 `启动服务提供者` 是两个比较重要的步骤的悬念，接下来两篇文章，我们来分别解析这两大流程。 ## 代码 https://github.com/xiaohuilam/laravel/blob/d081c918b7e582ec5b3f94316f44834466cec37d/vendor/laravel/framework/src/Illuminate/Foundation/Bootstrap/RegisterProviders.php#L1-L19 ### 解析 整个 RegisterProviders 都是粮衣，其没有任何功能功能代码，而是调用到了 `Illuminate\Foundation\ Application` 的 `registerConfiguredProviders` > 注意运行时实际并没有调用 Illuminate\Contracts\Foundation\Application 的...
> 随着前面 《02. Kernel Handle解析》 和 《03. ServiceProvider Register 解析》 的结束，我们接下来要分析的便是 启动服务提供者 这个步骤。 ## 代码 https://github.com/xiaohuilam/laravel/blob/d081c918b7e582ec5b3f94316f44834466cec37d/vendor/laravel/framework/src/Illuminate/Foundation/Bootstrap/BootProviders.php#L1-L19 同 `ServiceProvider Register ` 一样的，在 BootProviders 中也是调用了 `Illuminate\Foundation\Application::boot()` https://github.com/xiaohuilam/laravel/blob/d081c918b7e582ec5b3f94316f44834466cec37d/vendor/laravel/framework/src/Illuminate/Foundation/Application.php#L759-L782 首先判断是否 boot 过。 然后通过触发 $bootingCallbacks...
# RouteServiceProvider 详解 > 在 `RouteServiceProvider::boot` 阶段，所有路由都只是执行登记，匹配的逻辑是在 [02. HTTP Kernel Handle解析](https://github.com/xiaohuilam/laravel/issues/2) 的 dispatchToRouter 阶段。 我们先找到 `RouteServiceProvider.php` 在 [`config/app.php`](https://github.com/xiaohuilam/laravel/blob/6d9215c0a48aa68ef65d83c3ab8d1ba3c4e23d39/config/app.php) 的 `providers` 中定义的 RouteServiceProvider 其实是: https://github.com/xiaohuilam/laravel/blob/6d9215c0a48aa68ef65d83c3ab8d1ba3c4e23d39/config/app.php#L161 而这个类其实继承自 `Illuminate\Foundation\Support\Providers\RouteServiceProvider` https://github.com/xiaohuilam/laravel/blob/6d9215c0a48aa68ef65d83c3ab8d1ba3c4e23d39/app/Providers/RouteServiceProvider.php#L6-L9 我们分析 [`Illuminate\Foundation\Support\Providers\RouteServiceProvider`](https://github.com/xiaohuilam/laravel/blob/d081c918b7e582ec5b3f94316f44834466cec37d/vendor/laravel/framework/src/Illuminate/Foundation/Support/Providers/RouteServiceProvider.php#L1-L104) 的代码...
> 前言还没想好。 ## 服务提供者部分 `SessionServiceProvider` 没有 `boot` 方法，其 `register` 方法为 https://github.com/xiaohuilam/laravel/blob/ca57c288f7825c42550333b613440cb4e824b3ad/vendor/laravel/framework/src/Illuminate/Session/SessionServiceProvider.php#L15-L22 作用 - 单例注册 `Illuminate\Session\SessionManager` 为 `session` - 单例注册 `Illuminate\Session\Store` 为 `session.store` > 具体生成 `Illuminate\Session\Store` 对象的过程，由你 `.env` 配置 `SESSION_DRIVER` 而调用...
> Laravel 有不少门面类，如 `Session`、`View` 初一看令人诈舌，这些类的功能类不只一个，那么 Laravel 是怎么让这些奇葩的门面通往不止一个后门的？ ## 类声明 https://github.com/xiaohuilam/laravel/blob/ca57c288f7825c42550333b613440cb4e824b3ad/vendor/laravel/framework/src/Illuminate/Support/Manager.php#L3-L9 这是一个抽象类。 ## 属性 https://github.com/xiaohuilam/laravel/blob/ca57c288f7825c42550333b613440cb4e824b3ad/vendor/laravel/framework/src/Illuminate/Support/Manager.php#L10-L29 `$app` 是容器，这个 `$customCreators` 是什么鬼没看懂我们可以不管它。后面这个 `$drivers`，是一个数组，放的什么东西呢？ > driver 在英语中是驱动器的意思。 算了。。。再这么讲下去太拖了。我们拉到最后 ## 魔术函数 https://github.com/xiaohuilam/laravel/blob/ca57c288f7825c42550333b613440cb4e824b3ad/vendor/laravel/framework/src/Illuminate/Support/Manager.php#L144-L147 我们看到，当调用到当前实现类不存在方法时会调用 `$this->driver()` 下的同名方法。 https://github.com/xiaohuilam/laravel/blob/ca57c288f7825c42550333b613440cb4e824b3ad/vendor/laravel/framework/src/Illuminate/Support/Manager.php#L57-L75...
根据 Laravel 的 [Events 文档](https://laravel.com/docs/5.7/events) (中文版：[事件系统](https://laravel-china.org/docs/laravel/5.7/events/2280))， `EventServiceProvider` 的使用方法为： ```php /** * 注册应用中的其它事件。 * * @return void */ public function boot() { parent::boot(); Event::listen('event.name', function ($foo, $bar) { // }); }...
# Kernel Handle `App\Http\Kernel` 继承自 `Illuminate\Foundation\Http\Kernel` 类，所以本文章的分析主要集中在 [app/Http/Kernel.php](https://github.com/xiaohuilam/laravel/blob/master/app/Http/Kernel.php) 和 [vendor/laravel/framework/src/Illuminate/Foundation/Http/Kernel.php](https://github.com/laravel/framework/blob/5.7/src/Illuminate/Foundation/Http/Kernel.php) 两个类中 ## __construct 解析 因为 `App\Http\Kernel` 没有 __construct 方法，所以穿透到了 `Illuminate\Foundation\Http\Kernel` 的 __construct： https://github.com/xiaohuilam/laravel/blob/d081c918b7e582ec5b3f94316f44834466cec37d/vendor/laravel/framework/src/Illuminate/Foundation/Http/Kernel.php#L82-L103 首先是此方法传入参数的 ` __construct(Application $app, Router $router)` 声明，这里恰好使用了...
> 本章节以前面没有分析完成的 [02. HTTP Kernel Handle 解析](https://github.com/xiaohuilam/laravel/issues/2) 和 [06. RouteServiceProvider 详解](https://github.com/xiaohuilam/laravel/issues/6) 做铺垫，通过讲述其最后 `runController` 的内部逻辑，抛砖引玉，分析 Laravel 依赖注入的原理， > > 因为前面我们讲了容器对象的绑定的实现 (见：[10. 容器的 singleton 和 bind 的实现](https://github.com/xiaohuilam/laravel/issues/10))，所以在这里不再详述。 # 定义 > 在大型项目中，因为类的繁多，彼此需要调用到的代码的更多，如果我们在用到对象的每一个地方去 `new...
**类别**：Bug 反馈 **镜像名**：Packagist **上游路径**：packagist.org、api.github.com、 **镜像简介**： 因为 composer 官方镜像源 packagist.org 默认使用了 api.github.com/zipball 做为 dist，而贵镜像处理逻辑没有对 dist 做处理, 实质上没起到加速效果。  例如 [https://mirrors.sjtug.sjtu.edu.cn/packagist/p/0s1r1s/dev-shortcuts-bundle$f4f323c06b2346c9e734c57395fd17a0b9c18aa99fdbc99485949a5f23c1f4e0.json](https://mirrors.sjtug.sjtu.edu.cn/packagist/p/0s1r1s/dev-shortcuts-bundle$f4f323c06b2346c9e734c57395fd17a0b9c18aa99fdbc99485949a5f23c1f4e0.json) 这个包的 json 中的 dist 依旧为 github.com 的连接。