## 1、入口文件 用户发起的请求都会经过应用的入口文件，通常是`public/index.php`文件。当然，你也可以更改或者增加新的入口文件。 通常入口文件的代码都比较简单，一个普通的入口文件代码如下： ~~~ // 应用入口文件 // 定义项目路径 define('APP_PATH', __DIR__ . '/../application/'); // 加载框架引导文件 require __DIR__ . '/../thinkphp/start.php'; ~~~ 一般入口文件以定义一些常量为主，支持的常量请参考后续的内容或者附录部分。 > 通常，我们不建议在应用入口文件中加入过多的代码，尤其是和业务逻辑相关的代码。 ## 2、引导文件 接下来就是执行框架的引导文件，`start.php`文件就是系统默认的一个引导文件。在引导文件中，会依次执行下面操作： * 加载系统常量定义； * 加载环境变量定义文件； * 注册自动加载机制； * 注册错误和异常处理机制； * 加载惯例配置文件； * 执行应用； `start.php`引导文件首先会调用`base.php`基础引导文件，某些特殊需求下面可能直接在入口文件中引入基础引导文件。 > 如果在你的应用入口文件中更改了默认的引导文件，则上述执行流程可能会跟随发生变化。 ## 3、注册自动加载 系统会调用`Loader::register()`方法注册自动加载，在这一步完成后，所有符合规范的类库（包括`Composer`依赖加载的第三方类库）都将自动加载。 系统的自动加载由下面主要部分组成： 1. 注册系统的自动加载方法**`\think\Loader::autoload`** 2. 注册系统命名空间定义 3. 加载类库映射文件（如果存在） 4. 如果存在`Composer`安装，则注册\*\*`Composer`\*\*自动加载 5. 注册`extend`扩展目录 一个类库的自动加载检测顺序为： 1. 是否定义类库映射； 2. `PSR-4`自动加载检测； 3. `PSR-0`自动加载检测； 可以看到，定义类库映射的方式是最高效的。 ## 4、注册错误和异常机制 执行`Error::register()`注册错误和异常处理机制。 由三部分组成： * 应用关闭方法：`think\Error::appShutdown` * 错误处理方法：`think\Error::appError` * 异常处理方法：`think\Error::appException` > 注册应用关闭方法是为了便于拦截一些系统错误。 在整个应用请求的生命周期过程中，如果抛出了异常或者严重错误，均会导致应用提前结束，并响应输出异常和错误信息。 ## 5、应用初始化 执行应用的第一步操作就是对应用进行初始化，包括： * 加载应用（公共）配置； * 加载扩展配置文件（由`extra_config_list`定义）； * 加载应用状态配置； * 加载别名定义； * 加载行为定义； * 加载公共（函数）文件； * 注册应用命名空间； * 加载扩展函数文件（由`extra_file_list`定义）； * 设置默认时区； * 加载系统语言包； ## 6、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']`参数后才能继续。 ## 7、路由检测 如果开启了`url_route_on`参数的话，会首先进行URL的路由检测。 如果一旦检测到匹配的路由，根据定义的路由地址会注册到相应的URL调度。 5.0的路由地址支持如下方式： * 路由到模块/控制器/操作； * 路由到外部重定向地址； * 路由到控制器方法； * 路由到闭包函数； * 路由到类的方法； > 路由地址可能会受域名绑定的影响。 如果关闭路由或者路由检测无效则进行默认的**模块/控制器/操作**的分析识别。 > 如果在应用初始化的时候指定了应用调度方式，那么路由检测是可选的。 > 可以使用 \\think\\App::dispatch() 进行应用调度，例如： > App::dispatch(\['type' => 'module', 'module' => 'index/index'\]); ## 8、分发请求 在完成了URL检测和路由检测之后，路由器会分发请求到对应的路由地址，这也是应用请求的生命周期中最重要的一个环节。 在这一步骤中，完成应用的业务逻辑及数据返回。 建议统一使用`return`返回数据，而不是`echo`输出，如非必要，请不要使用`exit`或者`die`中断执行。 > 直接`echo`输出的数据将无法进行自动转换响应输出的便利。 下面是系统支持的分发请求机制，可以根据情况选择： ### 模块/控制器/操作 这是默认的分发请求机制，系统会根据URL或者路由地址来判断当前请求的模块、控制器和操作名，并自动调用相应的访问控制器类，执行操作对应的方法。 该机制下面，首先会判断当前模块，并进行模块的初始化操作（和应用的初始化操作类似），模块的配置参数会覆盖应用的尚未生效的配置参数。 支持模块映射、URL参数绑定到方法，以及操作绑定到类等一些功能。 ### 控制器方法 和前一种方式类似，只是无需判断模块、控制器和操作，直接分发请求到一个指定的控制器类的方法，因此没有进行模块的初始化操作。 ### 外部重定向 可以直接分发请求到一个外部的重定向地址，支持指定重定向代码，默认为301重定向。 ### 闭包函数 路由地址定义的时候可以直接采用闭包函数，完成一些相对简单的逻辑操作和输出。 ### 类的方法 除了以上方式外，还支持分发请求到类的方法，包括： 静态方法：`'blog/:id'=>'\org\util\Blog::read'` 类的方法：`'blog/:id'=>'\app\index\controller\Blog@read'` ## 9、响应输出 控制器的所有操作方法都是`return`返回而不是直接输出，系统会调用`Response::send`方法将最终的应用返回的数据输出到页面或者客户端，并自动转换成`default_return_type`参数配置的格式。所以，应用执行的数据输出只需要返回一个正常的PHP数据即可。 ## 10、应用结束 事实上，在应用的数据响应输出之后，应用并没真正的结束，系统会在应用输出或者中断后进行日志保存写入操作。 系统的日志包括用户调试输出的和系统自动生成的日志，统一会在应用结束的时候进行写入操作。 而日志的写入操作受日志初始化的影响。