在 NodeJS 生态中待了几年，我惊讶地发现很多初创公司使用 NestJS 仍然遇到同样的麻烦。可能因此浪费了不少时间。

人们常常称赞它在NodeJS后端开发的结构化方法。通常，他们只是大致浏览了一下文档，就认为这是一个很好的方式来“让每个人都在同一页面”，因为该框架有明确观点。

然而，如果文档看起来不错，这并不意味着在大规模使用该框架时不会有让你头疼的小毛病，这些小毛病可能会让你花掉很多时间。

NestJS 使用带有 依赖注入 的类。在使用类时，TypeScript 本身处理循环引用可能很棘手。当你添加装饰器和依赖注入时，情况很快会变得一团糟，最后你只能到处用 forwardRef 作为最后的救命稻草。

每次在 NextJS 中创建服务时，都需要遵循相同的操作步骤：

• 找到该服务所属的模块
• 把服务加到模块的 providers 里

每次有人想要用另一个模块的服务，这个人需要做以下事情：

• 找出服务所在的模块
• 如果服务不在模块的 exports 字段中，将其添加到该字段
• 找出我们想要使用服务的模块
• 如果源模块不在模块的 imports 字段中，也把它加进去

这是其他框架里没有的额外工作。你建的模块越多，你浪费的时间就越多。

文档中使用了一个CatsModule 例子，这可能促使许多公司为每个实体分别创建一个模块，从而陷入导出、导入和循环依赖的混乱，踏入导出、导入和循环依赖的地狱。

这是因为，通常每次重载时，它都需要重建整个依赖树，这还有一大缺点，它不太兼容热重载。

对此，还需要加上，默认情况下它使用 tsc（TypeScript 编译器），因此每次重新加载时都会运行类型检查，这使得速度变得更慢。这也是一个缺点，因为如果有 TypeScript 代码错误，服务器就不会重启，这在开发过程中会让人感到很麻烦。

tsc 无法编译依赖项中的 Typescript，因此你不能直接使用 NestJS 的单代码库 内部包依赖。有一个 单代码库模式，不过它需要用到 Webpack，Webpack 把所有后端代码打包成一个文件（我们通常不需要这种打包方式）。

可以看看Fastify，它差不多是一个比 Express 更方便的版本。

我对它的封装系统不太感冒，但你不必使用它。这可以只是一个简单的HTTP适配器，你的业务逻辑可以不依赖任何框架。

你也可以看一下vite-plugin-node，它可以用于热重载。据我所知，在 NodeJS 中，这是唯一一种不需要重启服务器就能实现热重载的方法，非常迅速。

很多人都觉得，如果用微框架，最终代码会变得一团糟。依我的经验，这并不一定，这完全取决于你怎么和同事一起工作。

见过一些使用 NestJS 的代码库，它们非常混乱；也有一些使用微框架的代码库则非常整洁且易于操作，这样的情况让我印象深刻。

这个团队编写结构良好的代码库，同时还遵循编码标准，特别是在代码审查时，对代码质量有着很高的期望。

使用 NestJS 的团队没有标准可言，每个人各行其是，这很快变得乱七八糟。所以，如果你不努力定义标准和提高代码质量，NestJS 并不会让你混乱的代码库变得整洁有序。