一、MVC模式
MVC模式（Model-View-Controller）是软件工程中的一种软件架构模式。
控制器（Controller）。负责转发请求，对请求进行处理。
视图（View）。界面设计人员进行图形界面的设计。
模型（Model）。程序员编写程序应有的功能（实现算法等），数据库专家进行数据管理和数据库设计（可以实现具体的功能）。即，数据和改变数据的操作。
可参考：https://laravelacademy.org/post/9614.html
二、框架结构
单一入口使得每一个请求都需经过这个入口文件处理，文件由此开始进行分发，减少重复存在一些通用的初始化操作，更容易管理Controller层。
路由：
路由是对来自客户端的请求的URL解析，并把指定的URL分派给对应的 Controller 来处理。
一个Controller控制器又是由一组具有相关功能的Action组成，Action方法是一个URL访问的最小单元。
路由就是找到这个控制器文件，并且执行它下面的方法。
数据模型：
1、数据库类的实现
2、数据模型层理论
对象关系映射（Object Relational Mapping，简称ORM、O/RM 或 O/R mapping）。
把数据库中的一个表直接映射为一个对象，基于这个对象进行赋值、保存等操作，并且减少写SQL语句，提高开发效率。
PO（persistant object）: 与一个数据库中的表的一行记录相对应的对象，称之为PO持久对象。PO中应该不包含任何对数据库的操作（也就是只有属性，没有方法），它仅仅是对表记录的映射。
BO（business Object）: 主要作用是把业务逻辑封装为一个对象。这个对象可以包括一个或者多个其他对象。比如出货单就包含有商品简介、订单详情、消费者信息等。商品简介对应一个PO，订单详情对应一个PO，消费者联系信息对应一个PO。建立一个对应出货单的BO对象处理出货单，每个BO包含这些PO。这样处理逻辑时，可以针对BO去处理。
VO（Value Object，值对象）: 界面显示的数据对象，一个界面对应一个VO对象。
DTO（Data Transfer Object）: 传输PO对象到VO进行一些过滤。它可以用在任何需要数据传输的地方。
注意：在创建PO、DTO、VO时，不要给这些对象赋初始默认值。
传统的ORM模式提倡数据和数据操作分离。而在Active Record中，模型层集成了ORM的功能，它们既代表实体，包含业务逻辑，又是数据对象，并负责把自己存储到数据库中，存储的这一部分代码是在父类中实现好的，属于框架的一部分，模型只需要简单调用父类的方法来完成持久化。在Active Record模式中的数据对象不再是PO对象，而是DAO（Data Access Object）对象。
比如，User类继承了父类Model，拥有父类父类所拥有的增删改查等功能（比如调用save()方法，实现数据保存；但其内部还是使用SQL拼装实现数据库操作，只是封装好后使用ORM会自动生成SQL语句；一般用ORM实现简单的CURD操作，复杂的查询还是更倾向于使用原生的SQL实现），进而User这个PO对象上升为一个Dao对象。
Service：把一系列的数据库操作组合起来，称之为Service。向上负责接收页面传递的参数以及数据的传输，向下负责与数据库打交道。
视图：
早期，使用smarty等专业的模板引擎来做视图层，后期，随着前后端分离理念的发展以及前端MVC框架的诞生，越来越多涉及显示的工作都由前端JavaScript +JSON来实现了。MVC中的显示层开始轻量化、API化发展。
三、框架加强
1、命名空间
详见：https://www.php.net/manual/zh/language.namespaces.basics.php
2、自动加载
composer自动加载一共支持4种自动加载方式：
PSR-0：由于PHP5.3之后才有的namespace这样的高级属性，所以低于此版本的，PSR组织用了一个伪namespace（通过命名的下划线来映射目录结构）的做法来模拟命名空间。
被结合为一个单一的键值对数组，存储至 autoload_namespaces.php 文件中。
PSR-4（推荐）：转换成namespace与文件目录的MAP形式，并存在 autoload_psr4.php 文件中，可以在此文件中找到真实路径
class-map：支持自定义加载不遵循PSR-0/4规范的类库。要配置它指向需要的目录，以便能够准确搜索到类文件。会遍历此目录然后将里面的类文件和路径一一对应，存放在autoload_classmap.php 内。
直接包含file：可以直接将文件包含进来。安装后会存放在 autoload_files.php 文件中。
详见： https://www.cnblogs.com/cshaptx4869/tag/Composer/
3、错误处理机制
set_error_handler()
set_exception_handler()
详见：https://www.cnblogs.com/cshaptx4869/p/10454086.html
4、控制反转 IOC（inversion of control）与 依赖注入DI（dependency injection）
控制反转是面向对象开发中的一种设计思想。IOC意味着将你设计好的对象交给容器控制，而不是直接在你的对象内部控制。
如何理解？明确“谁控制谁，控制什么，为何是反转，哪些方面反转了”。
谁控制谁，控制什么：传统面向对象程序设计，我们直接在对象内部通过new进行创建对象，是程序主动去创建以来对象；而IOC是有专门一个容器来创建这些对象，即由IOC容器来控制对象的创建；所以，是IOC容器控制对象，主要控制了外部资源获取（不只是对象创建，还包括比如文件等）。
为何是反转，哪些方面反转了：传统下是自己在对象中主动控制去直接获取依赖对象；反转则是由容器来帮忙创建及注入依赖对象，由于容器帮我们查找及注入依赖对象，对象只是被动接受依赖对象，所以是反转；总结一下就是，以前是由应用程序控制资源创建，现在控制权转移到了IOC容器，所以叫控制反转。
为什么这么做，这么做的意义何在？
依赖注入，是组件之间依赖关系由容器在运行期决定。即由容器动态地将某个依赖关系注入到组件之中。依赖注入的目的并非是为软件系统带来更多功能，而是为了调高组件重用的效率，并为系统搭建一个灵活、可扩展的平台。通过依赖注入机制，我们只要通过简单的配置，而无需任何代码就可指定目标需要的资源，完成自身的业务逻辑，而不需要关系具体的资源来自何处，由谁实现。依赖注入降低了创建对象的成本，使得对象之间松耦合。
DI的关键是“谁依赖谁，为什么需要依赖，谁注入谁，注入了什么”。
为什么需要依赖：应用程序需要IOC容器来提供对象需要的外部资源。
谁注入谁：IOC容器注入应用程序某个对象，应用程序依赖的对象。
注入了什么：注入某个对象所需要的外部资源（包括对象、资源、常量数据）。
DI和IOC是相辅相成的概念，IOC的实现是使用了DI，而DI的目的就是为了实现IOC。
依赖注入DI和控制反转IOC是对同一件事情的不同描述，它们描述的角度不同。依赖注入是从应用程序的角度在描述，应用程序依赖容器创建并注入它所需要的外部资源。而控制反转是从容器的角度在描述，容器控制应用程序，由容器反向的向应用程序注入应用程序所需要的外部资源。
IOC会使用最合适的策略来管理对象，需要使用单例的地方，容器就始终只提供一个对象。需要使用多例的时候，容器就每次帮我们创建一个新对象（当然也可以手动告诉容器怎么做）。
实际上IOC容器本身也就是个大对象，在整个生命周期里保证只有一份。可以保存在Session中，也可以保存在内存中。
5、拦截器和插件
拦截器可以用来作为权限控制、处理输入和输出等场景。
所有的拦截器组成一个拦截栈，按照从上到下进入，然后从下到上退出的顺序进行调用。
具体实现：可以定义一个拦截器接口InterceptorInterface，子类去实现，然后在配置中正则定义哪些请求需要使用（如定义数组）。
整个流程是，所有请求会按照配置中的拦截器栈，从上到下走一遍，激活拦截器前置preHandle方法，然后激活控制器自带的_bofore_方法（如果有的话），再激活当前需要执行的Action，紧接着是控制器再带的_after_方法（有的话），然后从上到下方向激活拦截器的postHandle方法。
实现插件也是同理，定义一组插件接口，然后用户自己扩展这个接口。框架只需要启动时自动读取所有实现了Plugin接口的类，并初始化注入框架的上下文环境即可。
6、Request增强和安全防御
XSS、CSRF、SQL注入等过滤
避免跨站请求伪造攻击的措施就是对写入操作采用非 GET 方式请求，同时在请求数据中添加校验 Token 字段，Laravel 也是这么做的