thinkphp5.0生命周期

一、入口文件

用户发起的请求都会通过应用的入口文件，一般是 public/index.php文件。固然，你也能够更改或者增长新的入口文件。

一般入口文件的代码都比较简单，一个普通的入口文件代码以下：

// 应用入口文件

// 定义项目路径
define('APP_PATH', __DIR__ . '/../application/');
// 加载框架引导文件
require __DIR__ . '/../thinkphp/start.php';

通常入口文件已定义一些常量为主，支持的常量请参考后续的内容或者附录部分。

一般，咱们不建议在应用入口文件中加入过多的代码，尤为是和业务逻辑相关的代码。

二、引导文件

接下来就是执行框架的引导文件，start.php文件就是系统默认的一个引导文件。在引导文件中，会依次执行下面操做：

• 加载系统常量定义；
• 加载环境变量定义文件；
• 注册自动加载机制；
• 注册错误和异常处理机制；
• 加载惯例配置文件；
• 执行应用；

若是在你的应用入口文件中更改了默认的引导文件，则上述执行流程可能会跟随发生变化。

三、注册自动加载

系统会调用Loader::register()方法注册自动加载，在这一步完成后，全部符合规范的类库（包括Composer依赖加载的第三方类库）都将自动加载。
系统的自动加载由两个部分组成：

1. 注册系统的自动加载方法 \think\Loader::autoload
2. 注册系统命名空间定义
3. 加载类库映射文件（若是存在）
4. 若是存在Composer安装，则注册Composer自动加载
5. 注册Extend扩展目录

一个类库的自动加载检测顺序为：

1. 是否认义类库映射；
2. PSR-4自动加载检测；
3. PSR-0自动加载检测；

能够看到，定义类库映射的方式是最高效的。

四、注册错误和异常机制

执行Error::register()注册错误和异常处理机制。

由三部分组成：

• 应用关闭方法：think\Error::appShutdown
• 错误处理方法：think\Error::appError
• 异常处理方法：think\Error::appException

注册应用关闭方法是为了便于拦截一些系统错误。

在整个应用请求的生命周期过程当中，若是抛出了异常或者严重错误，均会致使应用提早结束，并响应输出异常和错误信息。

五、应用初始化

执行应用的第一步操做就是对应用进行初始化，包括：

• 加载应用（公共）配置；
• 加载应用状态配置；
• 加载别名定义；
• 加载行为定义；
• 加载公共（函数）文件；
• 加载扩展配置文件（由extra_config_list定义）；
• 加载扩展函数文件（由extra_file_list定义）；
• 设置默认时区；
• 加载系统语言包；

六、URL访问检测

应用初始化完成后，就会进行URL的访问检测，包括PATH_INFO检测和URL后缀检测。

5.0的URL访问必须是PATH_INFO方式（包括兼容方式）的URL地址，例如：

http://serverName/index.php/index/index/hello/val/value

因此，若是你的环境只能支持普通方式的URL参数访问，那么必须使用

http://serverName/index.php?s=/index/index/hello&val=value

若是是命令行下面访问入口文件的话，则经过

$php index.php index/index/hello/val/value...

获取到正常的$_SERVER['PATH_INFO']参数后才能继续。

七、路由检测

若是开启了url_route_on参数的话，会首先进行URL的路由检测。

若是一旦检测到匹配的路由，根据定义的路由地址会注册到相应的URL调度。
5.0的路由地址支持以下方式：

• 路由到模块/控制器/操做；
• 路由到外部重定向地址；
• 路由到控制器方法；
• 路由到闭包函数；
• 路由到类的方法；

路由地址可能会受域名绑定的影响。

若是关闭路由或者路由检测无效则进行默认的模块/控制器/操做的分析识别。

若是在应用初始化的时候指定了应用调度方式，那么路由检测是可选的。
可使用 \think\App::dispatch() 进行应用调度。

八、分发请求

在完成了URL检测和路由检测以后，路由器会分发请求到对应的路由地址，这也是应用请求的生命周期中最重要的一个环节。

在这一步骤中，完成应用的业务逻辑及数据返回。

建议统一使用return返回数据，而不是echo输出，如非必要，请不要执行exit中断。

直接echo输出的数据将没法进行自动转换响应输出的便利。

下面是系统支持的分发请求机制，能够根据状况选择：

模块/控制器/操做

这是默认的分发请求机制，系统会根据URL或者路由地址来判断当前请求的模块、控制器和操做名，并自动调用相应的访问控制器类，执行操做对应的方法。
该机制下面，首先会判断当前模块，并进行模块的初始化操做（和应用的初始化操做相似），模块的配置参数会覆盖应用的还没有生效的配置参数。

支持模块映射、URL参数绑定到方法，以及操做绑定到类等一些功能。

控制器方法

和前一种方式相似，只是无需判断模块、控制器和操做，直接分发请求到一个指定的控制器类的方法，所以没有进行模块的初始化操做。

外部重定向

能够直接分发请求到一个外部的重定向地址，支持指定重定向代码，默认为301重定向。

闭包函数

路由地址定义的时候能够直接采用闭包函数，完成一些相对简单的逻辑操做和输出。

类的方法

除了以上方式外，还支持分发请求到类的方法，包括：
静态方法： 'blog/:id'=>'\org\util\Blog::read' 
类的方法：'blog/:id'=>'\app\index\controller\Blog@read'

九、响应输出

控制器的全部操做方法都是return返回而不是直接输出，系统会调用Response::send方法将最终的应用返回的数据输出到页面或者客户端，并自动转换成default_return_type参数配置的格式。因此，应用执行的数据输出只须要返回一个正常的PHP数据便可。

十、应用结束

事实上，在应用的数据响应输出以后，应用并没真正的结束，系统会在应用输出或者中断后进行日志保存写入操做。

系统的日志包括用户调试输出的和系统自动生成的日志，统一会在应用结束的时候进行写入操做。

而日志的写入操做受日志初始化的影响。