NestJS 实战经验分享书

在近几年的开发实践中，我越来越把 NestJS 当作一套工程化的思维方式来使用，而不仅仅是一个”好用的框架”。它让我们把复杂业务

拆成一个个可以独立演进的小单元，同时又能保持系统的整体协作性。下面的经验来自大量实际项目的落地，尽量把抽象的原则落到日常写

代码、搭结构、跑测试、做部署的每一个环节里。

在选型和架构上，我倾向以领域为驱动的模块化方案来推动开发节奏。首先要明确的是REST和GraphQL各有优劣，REST 更直观、契

约清晰，GraphQL 适合前端复杂查询场景。实际落地时，通常采用两

类产品线共存的做法：服务端提供稳定的 REST 接口，同时在需要灵

活查询和聚合时，通过 GraphQL 层对外暴露。核心是保证领域边界清晰：把领域概念分成若干模块，每个模块包含控制器、服务、DTO、

实体、以及必要的中间件、管道与拦截器。模块之间通过显式依赖注

入实现解耦，避免跨模块直接引用私有实现。

控制器与服务的职责要明确。控制器负责接收请求、校验输入、组

装响应，业务逻辑应当尽量放在服务层。DTO（数据传输对象）要与

输入输出绑定，结合 class-validator 做全局或分模块的校验管道。对于

错误处理，统一通过过滤器实现错误响应的结构化输出，避免在控制

器内堆积 try/catch。这样做的好处是后续若要切换日志系统、换数据库或者加缓存，都能在最小范围内完成，变动点集中，风险也更可控。

依赖注入（DI）是 NestJS 的核心能力之一。设计时应留出清晰的提供者边界，尽量避免循环依赖和直接导入实现细节。把外部服务如数