@wdhwg001 NestJS 抄 Java 的 Spring 那一套，各种注入，这些注入都是单例，所以成员变量一般不会做写操作。但是这种注入的玩法和直接走 Class 的 static 函数调用没啥区别，看不出多有面向对象编程，目前看到这么做的好处就是做单元测试可以随意 Mock，以及在启动的时候预先实例化对象，避免涌进来的前几个请求慢一丢丢。

我最近才做完一个基于 Node 的代理网关的选型，可以给一些性能上的数据。

环境：
CPU：8700k 默频
内存：4x16G C19 2666 频率
系统：Manjaro 20.2.1
Node 版本：14.15.4

写一个 hello work 接口，单 Node 进程运行，同时用 wrk 1 个线程去压测

纯内置 HTTP 库：QPS 3.8~3.9w, 内存占用 56~58MB
Fastify：QPS 3.8~4w, 内存占用 58~62MB，开了控制台日志 QPS 在 2.2w 左右
NestJS(Fastify 适配器，使用单例注入的 Service)：QPS 3.6w ，内存占用 63MB 左右
NestJS(Fastify 适配器，使用了{ scope: Scope.REQUEST }参数注入的 Service，即一个请求实例化一个对象)：QPS 2.2w ，内存占用 81~105MB
NestJS(Fastify 适配器，不使用注入 Service，自己 new Service)：QPS 3.1w ，内存占用 62MB
NestJS(Fastify 适配器，不使用注入 Service，直接把 Service 的函数弄成 static 来调用)：QPS 3.6w ，内存占用 59~60MB

结论就是推荐使用 Fastify 的适配器，尽量走它的注入方式，比较工程化。