nestjs express fastify

不一定。考虑这几点再决定：

• 性能瓶颈在哪：大多数业务系统的瓶颈是数据库 / 网络 IO，HTTP 框架带来的差异微乎其微。切 Fastify 不会让”慢接口”变快
• 生态成本：Express 中间件生态比 Fastify 大一截，迁移要逐个替换
• 团队熟悉度：调试问题、看错误栈，Express 资料更多

建议：

• 新项目、追求极致性能 / 想用 schema validation → 直接上 Fastify
• 老项目、依赖一堆 Express 中间件、性能不是瓶颈 → 留在 Express，不折腾

这其实是 NestJS 设计哲学里很关键的一点——面向接口编程，而不是面向具体实现。具体有这几个动机：

1. 避免被单一框架绑死（防供应商锁定）

Express 已经多年没有大版本更新，社区一度担心它停滞；Fastify、Hyper-Express、uWebSockets 等新库在性能、特性上不断迭代。如果 Nest 把 Express 写死在内核里，一旦底层换代，整个 Nest 生态都得跟着大改。

抽象出 HttpAdapter 接口之后，Nest 自己只依赖”一个能注册路由、能写响应”的契约，谁实现这个契约都行。Express 老了换 Fastify、Fastify 老了换下一个，都不影响业务代码。

2. 让用户按场景选最合适的引擎

不同场景需求不同：

• CRUD 后台：Express 生态完整、调试方便 → 用 Express
• 高并发网关 / BFF：QPS 敏感 → 用 Fastify（快约 2 倍）
• 极致低延迟：考虑 uWebSockets 适配器
• Serverless：用专门优化冷启动的适配器

如果框架强绑定一个 HTTP 库，开发者要么忍受不合适的性能，要么放弃整个框架。

3. 真正的”协议无关”AOP

这是和 NestJS 自身定位连在一起的：Nest 不只是”HTTP 框架”，它还要支持 WebSocket、TCP/Redis/NATS/Kafka 微服务、GraphQL 等多种协议。HTTP 只是其中一种。既然要做”协议无关”的 Guard / Interceptor / Filter（通过 ArgumentsHost / ExecutionContext 抽象），那 HTTP 这一层自然也要可替换，不能耦合到 Express。

4. 便于测试

抽象出 Adapter 之后，单元测试可以传一个 Mock Adapter 进去，不必真的起一个 HTTP 服务器，启动速度和稳定性都好很多。

5. 一句话总结

Nest 不想做 Express 的”上层语法糖”，它想做一个协议无关的应用框架。HTTP 库可换、传输协议可换，业务代码（Controller / Service）保持不变——这才是它和”裸 Express + 一堆约定”的本质区别。

结论先行：Nest 中间件底层就是 Express 中间件（在 Express 适配器下），但被 Nest 包装了一层，让它能享受 DI、装饰器、模块系统。

1. 函数式中间件——和 Express 完全一样

最简单的写法和 Express 没区别：

1
2
3
4
5
6
7
// logger.middleware.ts
import { Request, Response, NextFunction } from "express";

export function logger(req: Request, res: Response, next: NextFunction) {
  console.log(`[${req.method}] ${req.url}`);
  next();
}

2. 类式中间件——Nest 才有的写法

类式中间件可以注入其他 service，享受完整的 DI 能力：

1
2
3
4
5
6
7
8
9
10
11
12
13
// logger.middleware.ts
import { Injectable, NestMiddleware } from "@nestjs/common";
import { Request, Response, NextFunction } from "express";

@Injectable()
export class LoggerMiddleware implements NestMiddleware {
  constructor(private readonly logService: LogService) {} // ✅ 可以注入 service

  use(req: Request, res: Response, next: NextFunction) {
    this.logService.write(`${req.method} ${req.url}`);
    next();
  }
}

3. 注册方式不同

1
2
3
4
5
6
7
8
9
10
// app.module.ts
@Module({})
export class AppModule implements NestModule {
  configure(consumer: MiddlewareConsumer) {
    consumer
      .apply(LoggerMiddleware)
      .exclude({ path: "health", method: RequestMethod.GET })
      .forRoutes(UsersController); // 只对 UsersController 生效
  }
}

4. 执行时机：中间件 → Guard → Interceptor → Pipe → Handler

中间件是最早执行的层（紧贴 HTTP 库），所以拿到的还是裸的 req / res，没有 Nest 的请求上下文。需要读 @Roles() 之类的元数据，用 Guard 不要用中间件。

5. 一句话总结

• 函数式中间件 = Express 中间件（兼容性写法）
• 类式中间件 = Express 中间件 + DI + 装饰器友好的注册方式
• 切到 Fastify 后，类式中间件依然能用，只是 req / res 类型要换成 Fastify 的

不是。 两者解决的问题不同，只是表面上”都能拆分代码”，但定位完全不同。

Express 的 Router：纯路由组合工具

1
2
3
4
5
6
7
8
// users.routes.js
const router = express.Router();
router.get("/", listUsers);
router.post("/", createUser);
module.exports = router;

// app.js
app.use("/users", require("./users.routes"));

它做的事就一件——把一组路由打包成可挂载的子树。仅此而已。

Nest 的 @Module：DI 容器的边界 + 路由 + 生命周期

1
2
3
4
5
6
7
@Module({
  imports: [TypeOrmModule.forFeature([User])], // 引入其他模块的能力
  controllers: [UsersController],               // 路由（≈ Router 的部分）
  providers: [UsersService, UserRepository],    // 本模块的可注入服务
  exports: [UsersService],                      // 哪些 provider 给别的模块用
})
export class UsersModule {}

它至少承担四种职责：

1. DI 作用域边界：UsersService 默认只在 UsersModule 内可见，要给别的模块用必须显式 exports
2. 依赖关系图节点：imports 形成模块依赖图，Nest 据此决定实例化顺序和单例共享范围
3. 路由组合（这部分才和 Express Router 重合）：controllers 里的 @Controller('users') 等价于 app.use('/users', router)
4. 生命周期钩子：模块可实现 OnModuleInit / OnApplicationBootstrap 等，启动时按依赖顺序触发

对比表

举个例子说明差异

1
2
3
4
5
6
7
8
9
10
// OrderService 只在 OrderModule 里被声明
@Module({ providers: [OrderService] })
export class OrderModule {}

// UserModule 没 import OrderModule 就用不了 OrderService
@Module({
  // imports: [OrderModule], ← 没写就报错
  providers: [UserService], // UserService 里 inject OrderService 会失败
})
export class UserModule {}

Express 不会有这种”看不见”的限制——任何文件 require 一下就用了。Nest 用 @Module 强制你显式声明依赖，换来的是清晰的边界、可测试性、和大型项目的可维护性。

一句话总结：Express Router 是”路由的子文件夹”；Nest @Module 是”一个迷你应用 + 它管的路由”，更接近 Java Spring 的 @Configuration / Angular 的 NgModule。