生命周期

本篇对 ginkgo 的应用请求的生命周期做大致的介绍，以便于开发者了解整个执行流程。

入口文件

用户发起的请求都会经过应用的入口文件，通常是 public/index.php 文件。当然，也可以更改或者增加新的入口文件。

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

// 定义应用目录
define('GK_PATH_APP', __DIR__ . '/../app/'); //应用目录
// 加载框架引导文件
require(__DIR__ . '/../ginkgo/boot.php');

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

通常，不建议在入口文件中加入过多的代码，尤其是和业务逻辑相关的代码。

引导文件

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

• 加载系统常量定义
• 注册自动加载机制
• 注册错误和异常处理机制
• 加载默认配置文件
• 执行应用

boot.php 文件首先会调用 base.php 初始化文件，某些特殊需求下，可以直接在入口文件中加载初始化文件。

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

注册自动加载

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

系统的自动加载由下面主要部分组成：

• 注册系统的自动加载方法 ginkgo\Loader::autoload
• 如果存在 Composer 安装，则注册 Composer 自动加载
• 注册 extend 扩展目录

注册错误和异常机制

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

由三部分组成：

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

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

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

应用初始化

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

• 加载应用配置
• 加载扩展配置文件
• 加载公共文件
• 设置默认时区
• 加载系统语言包

URL 检测

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

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

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

如果配置了路由规则，会首先进行 URL 的路由检测。如果一旦匹配到路由，根据定义的路由地址会调度到相应的 URL。

分发请求

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

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

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

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

响应输出

控制器的所有动作都是 return 返回而不是直接输出，系统会调用 Response::send() 方法将最终的应用返回的数据输出到页面或者客户端。

应用结束

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

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

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