开启掘金成长之旅！这是我参与「掘金日新计划 · 12 月更文挑战」的第15天，点击查看活动详情。
前言
继续整理一下当前项目的情况，已满足：
- 启动一个服务，端口为 3000
- 可以处理get、post请求，操作数据库并返回自定义数据结构
- 可以通过接口访问经过 ejs 编译后的 html，并按照 ejs 的规则实现数据渲染
- 已经完成了一个前后端分离的项目
- 接口登录及角色权限管理
可见，这个项目已经逐步健全起来了！
Nest 生命周期
Nest应用程序处理请求并生成回应的过程被称为请求生命周期。使用中间件、管道、守卫和拦截器时，要在请求生命周期中追踪特定的代码片段的执行很困难，尤其是在全局、控制器或者路由的部件中。一般来说，一个请求流经中间件、守卫与拦截器，然后到达管道，并最终回到拦截器中的返回路径中（从而产生响应）。
一般来说，请求生命周期大致如下：
- 收到请求
- 全局绑定的中间件
- 模块绑定的中间件
- 全局守卫
- 控制层守卫
- 路由守卫
- 全局拦截器（控制器之前）
- 控制器层拦截器 （控制器之前）
- 路由拦截器 （控制器之前）
- 全局管道
- 控制器管道
- 路由管道
- 路由参数管道
- 控制器（方法处理器）
- 服务（如果有）
- 路由拦截器（请求之后）
- 控制器拦截器 （请求之后）
- 全局拦截器 （请求之后）
- 异常过滤器 （路由，之后是控制器，之后是全局）
- 服务器响应
Nest 核心
nest 核心其实就可以参考 Nest 文档的目录：
而对照文档可以发现，目录中的大部分我们已经使用到了：
- 控制器(Controller)和模块(Module)是最常用到的。
- 提供者是在 module 中挂载 Service 和 其他装饰器的。
- 守卫 则是 封装过的 public 和 role。
- 管道则是修饰 service 时使用到的。
- 拦截器和异常过滤器是处理统一返回体时用到的。
但是这些理论上的知识还是可以参考文档看吧。
下一步计划
现在的项目可以使用了，下一步的计划就是结合拦截器为项目添加一套完善的日志模块，方便问题回溯。
