目录前言一、NestJS 概念二、一个请求在 NestJS 中怎么走请求流程⭐️⭐️⭐️三、NestJS 运行架构图简图四、NestJS 的核心机制必须记住⭐️⭐️⭐️⭐️⭐️五、NestJS 核心成员全量速览表建议收藏六、重点核心成员「逐个突破」1、Module结构与边界⭐️⭐️⭐️⭐️⭐️2、Provider一切可注入的对象1、Service最核心3、Controller只做“协议层”4、请求增强类约束和治理1、Middleware请求最外层2、Guard访问控制层⭐3、Pipe参数治理层⭐4、Interceptor横切增强核心⭐5、Exception Filter异常兜底层⭐5、IoC / DI 依赖注入NestJS 的灵魂⭐️⭐️⭐️⭐️⭐️1、认识 IoC / DI2、NestJS 中的 IoC / DI①、定义 Provider能力②、消费 Provider不再 new③、用 Module 把能力“声明”给容器七、传统 MVC vs NestJS核心差异总览表重点版⭐️八、标准企业级 NestJS 分层建议规范版九、「企业业务」架构图十、NestJS、Fastify 和 Express 全方位对比十一、NestJS 默认使用 Express做了什么工作十二、如何将 NestJS 的运行时适配器由 Express 替换为 Fastify⭐️1、为什么 NestJS 可以“随便换” Express / Fastify2、替换为 Fastify标准做法1、安装依赖必须2、修改 main.ts3、Fastify 专属能力可选但常用前言NestJS Node.js 世界里的 Spring 框架。一、NestJS 概念NestJS 是一个基于 TypeScript 的、强约束、架构优先的 Node.js 服务端框架。它的核心目标不是“写得快”而是写得稳可扩展可维护可测试可演进NestJS 解决的是 Node.js 的「工程失控」问题传统 Node / Express 痛点NestJS 对应解决方案目录结构随意Module 强约束依赖注入缺失内置 IoC 容器中间件混乱Middleware / Guard / Interceptor / Pipe 分层业务代码和框架代码混在一起Controller / Service / Provider测试困难天然可 Mock、可单测大型项目难以协作清晰边界 依赖反转NestJS 是把 Java / Spring 的工程思想 引入到了 Node.js 世界。二、一个请求在 NestJS 中怎么走请求流程⭐️⭐️⭐️你会发现Controller 不重要它只是一个“转发器”真正干活的是 Provider三、NestJS 运行架构图简图四、NestJS 的核心机制必须记住⭐️⭐️⭐️⭐️⭐️如果你只记住了这个那就记住这个吧。NestJS 的核心机制包括模块化架构Module → 结构边界依赖管理依赖注入IoC / DI Container → NestJS 的灵魂管理 Provider 生命周期解耦、复用、测试友好ProviderService / Repository / Infra 等 → 一切能力的载体承载业务逻辑、数据访问、基础设施请求拦截体系Interceptor / Guard / Pipe / Filter → 请求增强横切逻辑企业级必备生命周期钩子 异步机制 → 支撑启动初始化、关闭清理、异步外部资源五、NestJS 核心成员全量速览表建议收藏分类类型 / 名称是否官方重要性作用推荐场景Provider 类Service❌约定俗成⭐⭐⭐⭐⭐核心业务逻辑业务处理、状态流转、任务编排Repository❌架构约定⭐⭐⭐⭐数据访问抽象DB 操作、ORM 封装Infra❌架构约定⭐⭐⭐⭐外部依赖封装MQ / Redis / SDK / OSSFactory✅⭐⭐⭐⭐动态创建 Provider 实例Redis / MQ / 多租户 DB / SDK 初始化Value✅⭐⭐⭐常量 / 配置注入feature flag、常量、枚举Class✅⭐⭐⭐⭐多实现替换支付渠道、多通道消息、存储服务Async✅⭐⭐⭐⭐异步初始化 Provider异步连接、远程配置加载Token✅⭐⭐⭐⭐抽象解耦多实现注入、接口替换、架构解耦Controller 类HTTP Controller✅⭐⭐⭐⭐⭐接收 REST 请求CRUD、业务接口WebSocket Gateway✅⭐⭐⭐实时双向通信聊天系统、实时通知Microservice Controller✅⭐⭐⭐⭐消息通信分布式任务、事件总线RPC Controller✅⭐⭐⭐远程调用内部服务 RPCGraphQL Resolver✅⭐⭐⭐GraphQL 请求处理查询/变更/订阅请求增强类Middleware✅⭐⭐⭐请求预处理日志、requestId、简单 authGuard✅⭐⭐⭐⭐权限控制登录校验、RBAC、数据权限Pipe✅⭐⭐⭐⭐参数校验 / 转换DTO 校验、类型转换、脏数据防护Interceptor✅⭐⭐⭐⭐⭐横切增强日志、性能监控、统一响应、缓存、事务Exception Filter✅⭐⭐⭐⭐异常捕获全局异常处理、日志、监控上报模块与应用Module✅⭐⭐⭐⭐⭐架构边界、依赖管理拆分业务模块、管理 ProviderApp / Application✅⭐⭐⭐⭐⭐系统启动与关闭启动模块、全局 Provider 管理核心系统级成员IoC Container✅⭐⭐⭐⭐⭐Provider 依赖管理Singleton / Request / Transient 管理Reflect Metadata✅⭐⭐⭐⭐装饰器元数据路由、验证、权限、AOPPlatform Adapter✅⭐⭐⭐平台适配Express / Fastify / Microservice重点关注 5 颗 ⭐ 和 4 颗 ⭐ 的。下面我们分别研究下这里面的重要成员。六、重点核心成员「逐个突破」1、Module结构与边界⭐️⭐️⭐️⭐️⭐️为什么需要 Module系统会越来越大不分模块 一团乱麻作用声明「这个模块有哪些能力」支持分层架构Controller → Service → Repository → Infra控制依赖可见性支持模块复用、懒加载定义业务边界保证系统清晰边界和高可维护性特性imports引入其他模块providers声明模块内部 Providercontrollers声明 Controllerexports输出可被其他模块使用的 Provider示例Module({imports:[],controllers:[],providers:[],exports:[]})exportclassUserModule{}2、Provider一切可注入的对象定义凡是能被 Nest IoC 注入的对象都是 Provider。重要性一切业务 和 基础设施 都写在 Provider 中。作用承载业务逻辑数据访问基础设施封装原则单一职责精简 Controller → Provider 专注业务可替换、多实现Token / Class ProviderProvider 生命周期三种作用域Scope生命周期特点Singleton应用启动实例化 → 全局共享 → 应用关闭销毁Request每次请求生成实例 → 请求结束销毁Transient每次注入生成实例 → 使用完销毁Provider 主要包括以下成员ServiceRepositoryCache / MQSDK 封装工具类企业级应用Service 调用 Repository Infra → 保证 Controller 薄Factory / Async Provider → 异步初始化外部资源Token / Class Provider → 支持支付渠道、消息通道替换1、Service最核心NestJS 的 Service是 IoC 容器中的“业务能力单元”它负责表达业务规则、编排业务流程业务正确性而不是处理技术细节。Service 的本质非常重要维度本质架构层面Application / Domain 层的载体IoC 角度被容器托管的可注入对象职责角度业务规则 业务流程编排可测试性可 Mock、可独立测试的纯逻辑单元✅ Service 应该做的事类型举例业务规则状态流转、校验业务流程下单 → 锁库存 → 支付 → 发通知事务控制DB 事务 / 分布式事务资源协调DB Redis MQ业务抽象统一业务接口❌ Service 不应该做的事禁止原因解析 HTTP 请求属于 Controller操作 Request / Response破坏分层写 SQLRepository 的职责写 Redis Key 细节Infra 关注点关心 UI 展示Presentation 关注点示例Injectable()exportclassUserService{}3、Controller只做“协议层”Controller 是 NestJS 的“传输适配层Transport Adapter”而不是业务层。Controller 的职责必须克制接收请求参数提取返回响应❌ 不写业务逻辑Controller 的本质非常重要维度本质架构层Presentation Layer表现层职责协议适配 请求入口复杂度应该极低生命周期被 IoC 管理可替换性可以被 GraphQL / RPC / MQ 替代Controller 不是核心逻辑所在而是“可被替换的一层壳”。与 MVC 架构的 Controller 过于肥大不同NestJS 刻意对 Controller 做了瘦身业务逻辑全部下沉到 ServiceController 只负责“接、转、发调”。Controller 越薄系统越健康。✅ Controller 能干什么明确边界职责说明路由声明Controller / Get协议绑定HTTP / GraphQL / RPC参数获取Body / Query / ParamDTO 校验Pipe class-validator调用 Service只调用、不实现返回结果统一响应结构❌ Controller 禁止做的事红线禁止项为什么写业务规则破坏分层操作数据库严重越权写 Redis / MQInfra 泄漏try/catch 业务异常应交给 Filter拼装复杂对象应在 ServiceController 的典型结构标准范式Controller(orders)exportclassOrderController{constructor(privatereadonlyorderService:OrderService,){}Post()create(Body()dto:CreateOrderDto){returnthis.orderService.create(dto);}}Controller 的分类企业级常见REST Controller最常见RPC / 微服务 ControllerGraphQL ResolverController 的另一种形态BFF Controller前端友好好 Controller 的 5 条铁律设计原则每个方法 ≤ 5 行只做参数映射不写 if / for只依赖 Service / Facade返回 DTO / ViewModel4、请求增强类约束和治理定义请求增强类 不处理业务本身而是对“请求/响应生命周期”进行增强、约束、治理的组件。它们的共同特点是关心 请求什么时候来、是否允许进入、如何变形、如何返回、如何兜底是 AOP面向切面编程思想的具体落地❌ 不关心具体业务作用在请求进入 Controller 前、响应返回前进行增强保证 Controller 只处理请求入口业务逻辑在 ProviderNestJS 的五大请求增强类官方类型执行位置核心职责Middleware最外层原始请求预处理GuardController 之前是否允许进入Pipe参数进入 Controller 之前校验 / 转换InterceptorController 前后横切增强Exception Filter异常抛出后统一异常处理1、Middleware请求最外层定位对原始 Request / Response 做最早处理特点基于 Express / Fastify无法使用 DI或能力有限更偏“框架级”典型用途requestId 注入原始日志CORS简单鉴权不推荐复杂❌ 不适合复杂权限业务逻辑依赖 Service 的场景2、Guard访问控制层⭐定位决定“这个请求有没有资格进入 Controller”特点返回 boolean / Promise可以使用 DI强语义是否放行典型用途登录校验RBAC / ABAC 权限数据级权限是否能访问某资源canActivate(context:ExecutionContext):boolean{constreqcontext.switchToHttp().getRequest()return!!req.user}Guard 是权限体系的唯一正解3、Pipe参数治理层⭐定位参数进入 Controller 前的“质量控制器”特点在参数级别执行可转换 / 可抛错强配合 DTO class-validator典型用途参数校验类型转换默认值填充防脏数据Body(newValidationPipe())create(Body()dto:CreateUserDto){}Pipe 参数防火墙4、Interceptor横切增强核心⭐定位Controller 前后包裹执行特点可拿到返回值可修改响应可做 AOP典型用途非常关键统一响应格式日志 性能统计缓存事务控制幂等控制returnnext.handle().pipe(tap(()console.log(after)),)Interceptor 是 NestJS 的灵魂5、Exception Filter异常兜底层⭐定位异常统一收口特点捕获 throw 出来的异常可分类处理可上报监控典型用途HTTP 异常统一格式错误码规范Sentry / 日志系统Catch(HttpException)exportclassHttpFilter{}Filter 系统稳定器5、IoC / DI 依赖注入NestJS 的灵魂⭐️⭐️⭐️⭐️⭐️1、认识 IoC / DIIoC控制反转是一种新的设计思想——提供了另一种创建对象的方式不用 new。DI依赖注入是 IoC 最主流、最工程化的实现方式DI 容器在运行时把对象所需的依赖“注入”进去。IoC 的核心反转点维度传统方式IoC创建对象自己 new容器创建管理依赖对象自己容器统一管理生命周期不可控可配置替换实现困难极其容易从“对象控制一切” → “容器控制一切”常见 DI 方式方式示例构造函数注入NestJS / Spring属性注入Angular方法注入少见NestJS 使用的是 构造函数注入最安全。2、NestJS 中的 IoC / DI不理解 IoC / DI就永远只是在“用 NestJS 写接口”而不是“用 NestJS 构建系统”。NestJS 的核心能力本质上是一个“强约束、强治理的 IoC 容器”。IoC 是“控制权反转”DI 是“反转的具体实现方式”。作用管理 Provider 生命周期Singleton / Request / Transient支撑模块间解耦、可替换实现、可 Mock 测试核心价值解耦 → Controller / Service / Repository 不直接创建依赖复用 → 同一 Provider 可被多个模块注入测试友好 → Mock / 替换 Provider 容易「没有 IoC」会发生什么对照组classPaymentService{pay(){returnpay success}}classOrderService{privatepaymentServicenewPaymentService()createOrder(){returnthis.paymentService.pay()}}❌ 问题OrderService 强依赖 PaymentService无法替换实现难测试、难扩展使用 NestJS IoC 的最小示例推荐记住①、定义 Provider能力Injectable()exportclassPaymentService{pay(){returnpay success}}②、消费 Provider不再 newInjectable()exportclassOrderService{constructor(privatereadonlypaymentService:PaymentService,){}createOrder(){returnthis.paymentService.pay()}}OrderService 不关心 PaymentService 怎么来的③、用 Module 把能力“声明”给容器Module({providers:[PaymentService,OrderService],})exportclassOrderModule{}到这里为止OrderService 的依赖关系已经“声明完毕”实例创建权完全交给 Nest根据上述“①、②、③”整个典例来看当 Nest 启动时发生了什么IoC 真正生效的地方扫描 OrderModul发现 PaymentService、OrderService解析 OrderService 构造函数参数自动创建 PaymentService注入进 OrderService‼️OrderService 从来没 new 过任何东西。七、传统 MVC vs NestJS核心差异总览表重点版⭐️维度传统 MVCNestJS架构中心ControllerModule Provider设计核心请求 → 响应能力组合 依赖注入依赖管理手动 new / 引入IoC 容器统一管理业务组织Controller 膨胀Service 解耦、可组合扩展机制Hook / 中间件有限Guard / Pipe / Interceptor / Filter面向对象偏过程式强 OOP DDD 友好测试友好度较弱极强天然 Mock企业级能力中小项目为主天然支持大型系统八、标准企业级 NestJS 分层建议规范版src/├── modules/│ └── business/│ ├── business.controller.ts │ ├── business.service.ts ← 业务 │ ├── business.repository.ts ← 数据 │ ├── clients/│ │ └── aliyun.client.ts ← Infra │ ├── dto/│ └── business.module.ts ├── infra/│ ├── redis/│ ├── logger/│ └── queue/九、「企业业务」架构图十、NestJS、Fastify 和 Express 全方位对比维度ExpressFastifyNestJS定位轻量级 HTTP 框架高性能 HTTP 框架企业级应用框架抽象层级低接近原生 HTTP中HTTP Schema高平台级是否是应用框架❌❌✅默认 HTTP 内核自身自身Express可换 Fastify是否可替换 HTTP 内核❌❌✅核心设计思想Middleware 链Plugin SchemaModule Provider IoC架构中心app / routerserver / pluginModule / Provider依赖注入DI❌❌✅核心能力IoC 容器❌❌✅模块化能力❌❌✅AOP / 拦截体系❌❌✅Guard / Pipe / Interceptor / Filter请求生命周期治理手写部分完整、标准化Controller 概念❌❌✅Service 层约定约定一等公民DTO / 参数校验手写Schema 原生支持Pipe class-validator权限体系手写手写Guard官方模式异常处理Error MiddlewareError HandlerException Filter统一响应手写手写Interceptor事务 / 幂等 / 缓存手写手写Interceptor / Provider中间件机制MiddlewarePlugin更强Middleware最外层插件生态⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐基于 Adapter类型支持TS⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐性能⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐取决于底层高并发能力一般非常强强Fastify 模式测试友好度一般一般极强天然 Mock微服务支持❌❌✅官方GraphQL 支持❌❌✅WebSocket 支持手动插件官方支持学习成本低中高代码规范约束极低低高强约束项目规模适配小中中 → 超大典型项目简单 API / Demo高性能 API企业后台 / 中台 / BFF架构演进成本高中低可维护性易失控中等非常强是否适合大型团队❌⚠️✅十一、NestJS 默认使用 Express做了什么工作在 NestJS 中Express 只是“HTTP 运行时适配器Runtime Adapter”。其他所有“应用级能力”几乎全部由 NestJS 自己接管。NestJS应用框架 ↓ ExpressHTTP适配器/执行器 ↓ Node.js运行时Express 不再是“框架”而是“运行时引擎”层级负责者HTTP 协议Express路由注册NestJS请求生命周期NestJS权限 / 校验NestJS业务逻辑NestJS异常治理NestJS响应格式NestJS90% 的“应用逻辑”已经不在 Express 里了十二、如何将 NestJS 的运行时适配器由 Express 替换为 Fastify⭐️既然 Fastify 比 Express 性能更强大那么如何快速将 NestJS 的运行时适配器由 Express 替换为 Fastify 呢NestJS 默认使用 Express 时通过 Platform Adapter 抽象了 Web 层这就给了你替换的机会你只需要在 bootstrap 阶段替换 Adapter就可以无痛切换到 Fastify。1、为什么 NestJS 可以“随便换” Express / FastifyNestJS 的核心不直接依赖 Express而是依赖 nestjs/platform-* 适配层Nest Core ↓ Platform AdapterExpress/Fastify ↓HTTPServer这正是 NestJS IoC 适配器模式 的体现。2、替换为 Fastify标准做法1、安装依赖必须npm installnestjs/platform-fastify fastify⚠️ 不需要再装 express2、修改 main.tsimport{NestFactory}fromnestjs/coreimport{AppModule}from./app.moduleimport{FastifyAdapter,NestFastifyApplication,}fromnestjs/platform-fastifyasyncfunctionbootstrap(){constappawaitNestFactory.createNestFastifyApplication(AppModule,newFastifyAdapter(),)awaitapp.listen(3000,0.0.0.0)}bootstrap()✅ 到这里Express 已被彻底替换为 Fastify3、Fastify 专属能力可选但常用注册 Fastify 插件constappawaitNestFactory.create(AppModule,newFastifyAdapter(),)app.register(require(fastify/cors))注意Fastify 插件 ≠ Nest Middleware使用 Fastify Request / Replyimport{FastifyRequest,FastifyReply}fromfastifyGet()get(Req()req:FastifyRequest,Res()reply:FastifyReply){reply.send({ok:true})}一旦使用 Res()Nest 的响应拦截器将失效和 Express 一样