NestJS默认构建在Express之上，虽然提供了完善的模块化架构，但在高并发场景下，它的抽象层会带来一定的性能损耗。Fastify凭借更高效的路由匹配和序列化机制，在官方基准测试中吞吐量往往能达到Express的三倍左右。如果你的React应用后端接口延迟逐渐成为瓶颈，把NestJS服务迁移到Fastify是一个务实的选择。本文将围绕迁移的完整流程展开，包括路由改写、中间件替换、依赖注入调整以及与React前端的对接验证。
一、为什么Fastify性能更好
要理解迁移的价值，先得弄清楚Fastify快在哪里。第一个核心原因是Fastify内部使用了 find-my-way 这个激进的路由库，它基于基数树算法实现路由匹配，时间复杂度接近O(1)，而Express和NestJS默认使用的路由匹配是线性遍历，路由数量越多差距越明显。
第二个原因是Fastify的JSON序列化。它支持通过schema预先定义响应结构，利用 fast-json-stringify 生成针对性的序列化函数，比原生 JSON.stringify 快出一大截。对于返回大量结构化数据的接口，比如商品列表、订单记录，这个优化效果非常直接。
第三点是请求生命周期更精简。NestJS在请求进入处理函数之前，会经过Guard、Interceptor、Pipe、Filter等一系列装饰器驱动的层，每一层都有依赖注入和反射开销。Fastify的钩子机制是纯函数调用，链路短得多。下面的代码展示了同样一个查询接口在两个框架下的写法差异：
// NestJS 写法
@Controller('api/users')
export class UserController {
constructor(private userService: UserService) {}
@Get(':id')
@UseInterceptors(CacheInterceptor)
getUser(@Param('id', ParseIntPipe) id: number) {
return this.userService.findOne(id);
}
}
// Fastify 写法
fastify.get('/api/users/:id', {
preHandler: cacheHook,
schema: {
params: { id: { type: 'integer' } },
response: { 200: userSchema }
}
}, async (request, reply) => {
return userService.findOne(request.params.id);
});可以看到Fastify版本没有装饰器和反射，所有行为都是显式声明的。这种风格在小型项目里更直观，代码量也更少。
二、迁移的核心步骤
1. 安装依赖并搭建骨架
迁移的第一步是初始化Fastify工程。建议不要直接改动原有的NestJS代码，而是新建一个目录逐步搬运，这样出问题时可以随时回退。安装命令如下：
npm install fastify @fastify/cors @fastify/jwt @fastify/static npm install -D typescript @types/node tsx
其中 @fastify/cors 对应NestJS里的 enableCors，@fastify/jwt 对应 @nestjs/jwt，几乎每个NestJS的内置模块都能找到对应的官方插件，迁移成本比想象中低。
2. 改写路由和中间件
NestJS的路由由Controller装饰器定义，Fastify则直接注册处理函数。建议按业务域拆分插件文件，每个插件负责一组相关路由，这样能保持接近NestJS模块化的可维护性：
// routes/users.ts
export default async function userRoutes(fastify) {
// 对应 NestJS 的 POST /api/users
fastify.post('/api/users', {
schema: {
body: {
type: 'object',
required: ['username', 'email'],
properties: {
username: { type: 'string', minLength: 2 },
email: { type: 'string', format: 'email' }
}
}
}
}, async (request, reply) => {
const user = await fastify.userService.create(request.body);
reply.code(201).send(user);
});
// 对应 NestJS 的全局 Guard
fastify.addHook('preHandler', async (request, reply) => {
try {
await request.jwtVerify();
} catch (err) {
reply.code(401).send({ message: '未授权访问' });
}
});
}注意schema验证在这里取代了NestJS的DTO和ValidationPipe。Fastify使用JSON Schema规范，验证失败会自动返回400错误，并且请求体解析本身就基于schema做，性能比class-validator的反射方案好不少。
3. 替换依赖注入
NestJS的依赖注入容器是它的招牌，Fastify原生没有这套机制，但提供了 decorate API把服务挂到实例上，达到类似效果：
// app.ts
import Fastify from 'fastify';
import { UserService } from './services/user.service';
import userRoutes from './routes/users';
const fastify = Fastify({ logger: true });
// 注册数据库连接和业务服务
fastify.decorate('userService', new UserService());
// 注册路由插件
fastify.register(userRoutes, { prefix: '' });
await fastify.listen({ port: 3000, host: '0.0.0.0' });如果项目较大，服务依赖关系复杂，可以引入 awilix 这类轻量级注入容器配合使用。实践上大多数中小项目，直接用decorate加TypeScript的类型声明扩展就够用了，不必强行复刻NestJS的全部容器功能。
三、React前端对接与常见坑
对React前端来说，只要接口路径和响应结构不变，理论上不需要任何改动。但实际迁移中有几个坑需要特别留意。
第一个坑是错误响应格式。NestJS的异常过滤器返回的错误结构是 { statusCode, message, error }，而Fastify默认是 { statusCode, error, message }，字段顺序和内容有细微差别。如果前端axios的拦截器里写了类似 error.response.data.error 的取值逻辑，最好在后端统一一个错误处理器来对齐格式：
fastify.setErrorHandler((error, request, reply) => {
const statusCode = error.statusCode || 500;
reply.code(statusCode).send({
statusCode,
message: error.message,
error: error.name
});
});第二个坑是文件上传。NestJS用 @UseInterceptors(FileInterceptor) 处理multipart请求，Fastify需要引入 @fastify/multipart，且读取文件的方式是流式的，代码写法完全不同，前端用FormData上传的接口要重点回归测试。
第三个坑是响应序列化的严格性。一旦给路由定义了response schema，Fastify会严格按schema输出，多余字段会被自动删除。如果前端依赖后端偷偷返回的额外字段，迁移后这些字段会消失。解决办法是迁移初期干脆不定义response schema，等功能验证通过后再逐步补上，享受序列化优化的同时保证兼容。
最后建议采用灰度方式切换：先在NestJS前加一层反向代理，把流量按接口逐步转发到新的Fastify服务，观察日志和监控指标一到两周，确认没有异常后再完全下线老服务。配合React端的错误上报，基本可以做到无感知迁移，最终拿到性能提升的收益。