Nest 全流程
Nest 全流程
↓
模块与依赖注入
↓
装饰器 & Reflect Metadata
↓
请求生命周期（AOP）
↓
Nest 与 Express 的关系
↓
为什么 Nest 适合大项目
很多人学 NestJS 的过程是这样的：
- Controller、Service、Module 能写
- 装饰器一大堆，看得懂但记不住
- 一问「Nest 到底在帮我干嘛？」就懵了
本质原因只有一个：
Nest 是一个“靠结构和流程取胜”的框架，但我们一直在用 API 的方式学它。
① Nest 核心流程
HTTP Request
↓
Middleware
↓
Guard
↓
Pipe
↓
Controller
↓
Service
↓
Interceptor (before)
↓
Response
↑
Interceptor (after)
↑
Exception Filter
- Middleware：请求前置处理（和 Express 一样）
- Guard：权限 / 登录 / 是否允许进入业务
- Pipe：参数校验 + 类型转换
- Controller：只做路由和参数转发
- Service：真正的业务逻辑
- Interceptor：AOP（日志、耗时、包装返回值）
- Filter：兜底异常处理
Nest 的本质：
不是一个 Web 框架，而是一个“后端应用结构化框架”
Module & 依赖注入（Nest 的核心竞争力）
② 模块 & DI 关系图
AppModule
├── UserModule
│ ├── UserController
│ └── UserService
├── OrderModule
│ ├── OrderController
│ └── OrderService
-
Module = 依赖作用域
-
Provider = 容器里的实例
-
Nest 在启动时做了三件事：
- 扫描 Module
- 分析 Provider 依赖关系
- 构建 依赖图（Dependency Graph）
Nest 的依赖注入，本质是在启动阶段构建一棵 对象依赖树
装饰器 ≠ 语法糖
③ 装饰器 & Reflect Metadata 图
@Controller()
class UserController {
@Get('list')
getList(@Query('id') id: number) {}
}
背后真实发生的是：
Class / Method / Param
↓
Reflect.metadata
↓
Nest 在启动时读取 metadata
↓
生成路由 & 参数解析逻辑
装饰器不是 Nest 的魔法
Reflect Metadata 才是
前面已经研究过的例子：
Reflect.getMetadata('design:paramtypes', controller, 'method')
请求生命周期（AOP 顺序）
④ AOP 顺序图
Request
→ Middleware
→ Guard
→ Pipe
→ Interceptor (before)
→ Controller
→ Service
→ Interceptor (after)
→ Filter
→ Response
- Interceptor 是唯一前后都能插的
- Exception Filter 是异常才进
Nest 的 AOP 设计，本质是一个“责任链 + 洋葱模型”
Nest 和 Express 的关系
⑤ Nest 架构图
Nest Core
↓
Platform Adapter
↓
Express / Fastify
- Express：只负责 HTTP
- Nest：负责架构、生命周期、依赖管理
Express 是“能跑”，Nest 是“能长期维护”
总结
学 Nest 的正确顺序，从来不是：
❌ 装饰器 → API → Demo
而是：
✅ 架构 → 生命周期 → 再看 API
当你把这几张图真正想明白：
- 装饰器不再神秘
- Guard / Pipe / Interceptor 各就其位
- Nest 为什么适合中大型项目，也就不言自明了
