当前主流 Node.js Web 框架对比：Express、Fastify、NestJS、Koa、Hono 到 Next.js

Node.js 框架选型最容易掉进一个坑：

1	把所有框架放在同一张性能榜上，然后问哪个最快。

这其实不太有意义。

Express、Fastify、NestJS、Koa、Hono、AdonisJS、hapi、Next.js 解决的问题并不完全一样。有的是 HTTP 库，有的是企业级应用框架，有的是全栈 React 框架，有的是面向边缘运行时和 Web Standards 的轻量框架。

真正要问的不是“哪个框架最好”，而是：

1
2
3

我的项目到底需要多少框架约束？
我会部署在 Node.js 服务器、Serverless，还是边缘运行时？
团队更缺的是性能、规范、生态，还是长期维护性？

本文对比当前常见的 Node.js Web 框架和全栈框架：Express、Fastify、NestJS、Koa、Hono、AdonisJS、hapi、Next.js，并给出实际选型建议。

数据快照时间：2026-06-23。GitHub star 和 release 会持续变化，下面的数字只用于判断生态热度，不应该当成唯一选型依据。

一、先给结论

如果你只是想快速写一个通用 REST API，优先看：

1	Express 或 Fastify

Express 生态最大，资料最多，招人和维护都最容易。Fastify 更现代，性能更好，schema、插件和 TypeScript 体验也更完整。

如果你做的是团队项目、后台系统、微服务，想要明确的目录结构、依赖注入、模块化、守卫、拦截器、管道、OpenAPI、测试体系，可以看：

NestJS

NestJS 不是“轻量框架”。它的价值也不在轻，而在于给团队一个统一的工程语言。

如果你喜欢中间件模型，想要比 Express 更干净的 async/await 体验，但又不想被大型框架绑住，可以看：

Koa

Koa 很适合懂 Node.js 底层的人。它给得少，但给得干净。

如果你希望同一份代码能跑在 Node.js、Cloudflare Workers、Deno、Bun、AWS Lambda 等不同运行时，优先看：

Hono

Hono 的核心卖点不是“替代 Express”，而是 Web Standards、多运行时和非常舒服的 TypeScript 体验。

如果你想要 Laravel / Rails 那种全栈后端体验，可以看：

AdonisJS

它更适合完整业务系统，而不是只写几个接口。

如果你在维护企业老系统，或者非常在意安全默认值、插件边界和成熟的服务端能力，可以看：

hapi

hapi 不是这几年最热的选择，但它一直有自己的位置。

如果你做的是 React 网站、BFF、SSR、静态生成、数据加载和前端路由一体化，那应该看：

Next.js

但要记住，Next.js 不应该和 Express、Fastify 简单放在同一个维度比较。它首先是 React 全栈框架，然后才顺手承担一部分后端能力。

二、快速对比表

框架	当前定位	GitHub star	最新 release	适合场景
Next.js	React 全栈框架，SSR/SSG/BFF 一体化	140k	v16.2.9	React 网站、内容站、BFF、全栈应用
NestJS	企业级 Node.js 应用框架	75.9k	v11.1.27	团队项目、微服务、后台系统、复杂 API
Express	经典极简 Web 框架	69.1k	v5.2.1	通用 REST API、老项目、生态优先项目
Fastify	高性能、schema 驱动、插件化	36.5k	v5.8.5	高性能 API、TypeScript、结构化接口
Koa	洋葱模型中间件、极简 async 框架	35.7k	v3.2.1	轻量服务、自定义框架层、网关类服务
Hono	Web Standards、多运行时、轻量高性能	31.1k	v4.12.27	Edge、Serverless、Node/Bun/Deno 多运行时
AdonisJS	batteries-included TypeScript MVC 框架	19.0k core	v7.3.4	全栈后台、传统业务系统、CRUD 密集项目
hapi	安全、可扩展、企业级 HTTP 框架	14.8k	v21.3.0	企业服务、稳定老项目、插件边界清晰项目

从热度看，Next.js、NestJS、Express 仍然是最容易被团队接受的选择。

但从工程角度看，star 不是最重要的。真正重要的是框架和你的项目形态是否匹配。

一个内部管理后台，强行用极简框架，后面很容易长出一堆没人敢碰的自定义约定。

一个简单 Webhook 接收器，强行上 NestJS，也会显得太重。

三、Express：默认安全牌，但不要写成一锅粥

Express 仍然是 Node.js 后端世界最稳的默认选项之一。

它的优点很直接：

生态最大
入门简单
中间件多
资料多
招人容易
老项目迁移成本低

最小示例：

import express from "express";

const app = express();

app.get("/health", (req, res) => {
  res.json({ ok: true });
});

app.listen(3000);

Express 的问题也很直接：

1	它不会替你规定项目该怎么写。

这在小项目里是自由，在大项目里就是风险。

路由怎么分层，错误怎么处理，参数怎么校验，日志怎么打，鉴权怎么组织，响应格式怎么统一，这些都需要你自己定。

所以我对 Express 的建议是：可以用，但不要裸用。

至少要提前定好：

统一错误处理中间件
输入校验方案
日志方案
路由分层
业务 service 层
TypeScript 类型边界

如果团队没有能力维护这些约定，Express 很容易变成“前期快，后期乱”。

四、Fastify：更现代的 API 服务默认选择

如果今天从零开始写一个 Node.js API 服务，我会优先考虑 Fastify，而不是 Express。

原因不是 Express 不能用，而是 Fastify 在几个关键点上更适合现代项目：

性能好
插件体系清晰
schema 驱动
日志默认接近生产可用
TypeScript 支持更自然
输入校验和响应序列化可以统一管理

一个典型 Fastify 路由会长这样：

import Fastify from "fastify";

const fastify = Fastify({ logger: true });

fastify.get(
  "/users/:id",
  {
    schema: {
      params: {
        type: "object",
        properties: {
          id: { type: "string" },
        },
        required: ["id"],
      },
    },
  },
  async (request) => {
    return {
      id: request.params.id,
      name: "wxk1991",
    };
  }
);

await fastify.listen({ port: 3000 });

Fastify 最值得关注的是 schema。

很多接口问题本质上不是业务复杂，而是边界不清：

请求参数到底是什么？
响应结构到底是什么？
错误格式到底是什么？
哪些字段可以为空？

Fastify 鼓励你更早定义这些边界。这个习惯对长期维护非常有价值。

当然，Fastify 也不是没有成本。它比 Express 更有自己的体系，插件、decorator、hook、schema 这些概念需要团队学习。

但这笔学习成本通常是值得的。

五、NestJS：不是轻量，是秩序

很多人第一次看 NestJS，会觉得它太重：

Controller
Provider
Module
Guard
Interceptor
Pipe
Decorator
Dependency Injection

是的，它确实重。

但重不一定是缺点。真正的问题是你的项目是否需要这种重量。

NestJS 适合这些场景：

多人协作的中大型后端
后台系统
复杂权限体系
微服务
需要统一分层和依赖注入
希望框架提供测试、校验、OpenAPI、队列、缓存、WebSocket 等完整模式

NestJS 的核心价值不是性能，而是工程约束。

它让团队成员即使风格不同，也会被框架拉回同一套结构里。Controller 负责入口，Provider 负责业务能力，Module 负责边界组织，Guard 处理鉴权，Pipe 做校验和转换，Interceptor 做横切逻辑。

这对长期项目很重要。

但如果你只是写一个简单 API、一个脚本服务、一个 Webhook 接收器，NestJS 会显得有点过度设计。

我的建议是：

1 2	小项目不要为了“专业感”上 NestJS。中大型团队项目不要因为“怕重”而错过 NestJS。

六、Koa：适合愿意自己搭骨架的人

Koa 是 Express 原班思想的后续演进之一，核心是更干净的中间件模型。

它的洋葱模型很经典：

app.use(async (ctx, next) => {
  const start = Date.now();
  await next();
  const ms = Date.now() - start;
  ctx.set("X-Response-Time", `${ms}ms`);
});

请求先一层层进入中间件，业务处理完成后再一层层返回。这种模型非常适合做日志、鉴权、错误处理、链路追踪、网关逻辑。

Koa 的优点是干净。

Koa 的缺点也是干净。

它不给你完整的应用框架，不内置路由，不内置校验，不内置一堆企业能力。你需要自己挑选 @koa/router、校验库、日志库、错误处理方式。

所以 Koa 更适合有经验的团队，或者你本来就想在它之上搭一层自己的框架。

如果团队里大多数人只是想快速写业务，Koa 不一定比 Fastify 更省心。

七、Hono：Node.js 之外的新变量

Hono 是这几年 Node.js 后端选型里很值得关注的变化。

它的重点不是“又一个 Express 替代品”，而是：

1	基于 Web Standards，一套代码尽量跑在多个 JavaScript 运行时上。

最小示例：

import { Hono } from "hono";

const app = new Hono();

app.get("/health", (c) => {
  return c.json({ ok: true });
});

export default app;

这个导出方式天然适合 Cloudflare Workers、Deno、Bun、Serverless、边缘运行时，也可以跑在 Node.js 上。

Hono 适合：

Edge API
Serverless API
小而快的服务
多运行时部署
TypeScript 优先项目
想靠近 Web Request / Response 标准的项目

它不适合什么？

如果你的项目是传统 Node.js 大型后台，强依赖大量 Node 原生中间件，或者团队已经围绕 Express / NestJS 建了完整体系，Hono 未必是最省事的迁移目标。

另外，Hono 的生态更新很快。比如 2026-06-23 的 v4.12.27 是一次安全相关 release，使用 hono/jsx、hono/css 或 AWS Lambda API Gateway v1 adapter 的项目就应该及时升级。

这也说明一件事：越现代、越活跃的框架，越要把依赖升级和安全公告纳入日常维护。

八、AdonisJS：想要完整后端，就不要嫌它有主见

AdonisJS 和 Express、Koa、Hono 不是一类东西。

它更像 Laravel / Rails 在 Node.js 世界里的表达。

它会给你很多开箱即用的能力：

MVC 结构
路由
Controller
ORM
认证
验证
邮件
队列
缓存
限流
测试
CLI
Vite 集成

这类框架的优点是：

1	常见业务不用到处找 npm 包。

后台系统、管理平台、CRUD 密集应用、传统业务系统，很多时候缺的不是“自由”，而是“少做选择”。

AdonisJS 的成本也很明显：它有自己的世界观。

你要接受它的目录结构、生命周期、ORM、命令行、约定。如果团队只是想写几个无状态 API，它可能太完整。

但如果你要做一个长期业务系统，尤其是后端主导的应用，AdonisJS 值得认真看。

九、hapi：没那么热，但仍然稳

hapi 曾经是 Node.js 企业后端里很重要的选择。

这些年它不像 Next.js、NestJS、Hono 那样站在话题中心，但它的特点一直很稳定：

安全默认值
插件边界清晰
路由配置明确
企业服务经验丰富
对大型服务有成熟设计

hapi 适合那些非常在意可预测性和边界的项目。

它不像 Express 那样自由，也不像 NestJS 那样使用装饰器和依赖注入组织大型应用。它更强调配置、插件和明确的服务端能力。

如果是新项目，我一般不会把 hapi 作为第一推荐。

但如果你在维护已有 hapi 项目，或者团队很熟悉它，它仍然不是一个“过时到必须迁移”的选择。

技术选型不要只看热度。有些框架不热，但稳定、清楚、可维护。

十、Next.js：它不是后端框架，但会吃掉很多后端场景

Next.js 很特殊。

它不是传统意义上的 Node.js 后端框架。它首先是 React 全栈框架，解决的是页面、路由、渲染、数据加载、缓存、部署、构建和前后端边界问题。

但现实是，很多团队会用 Next.js 做：

官网
内容站
SaaS 前台
管理后台
BFF
表单提交
简单 API
SSR 数据聚合

这让它确实吃掉了不少原本属于 Express / Koa 的小后端场景。

如果你的后端逻辑主要服务于页面，Next.js 的 Route Handlers、Server Components、Server Actions、缓存和部署体系会很顺手。

但如果你的系统是复杂业务后端，比如权限复杂、接口很多、队列任务多、第三方系统集成多、需要独立扩展和独立发布，那我更倾向于把 Next.js 当前端和 BFF，而不是核心后端。

简单说：

1 2	页面驱动的全栈应用，可以 Next.js 优先。业务驱动的后端系统，还是 Express/Fastify/NestJS/AdonisJS 更清楚。

十一、我的选型建议

如果是个人项目、小工具、Webhook、轻量 API：

1	Hono 或 Fastify

Hono 适合多运行时和边缘部署，Fastify 适合更传统的 Node.js API 服务。

如果是普通公司业务 API：

1	Fastify 或 NestJS

团队小、希望灵活，用 Fastify。团队大、业务复杂、需要统一规范，用 NestJS。

如果是老项目维护：

1	不要为了追新强行重写

Express、Koa、hapi 只要结构清楚、依赖可维护、安全更新跟得上，就不应该因为“不够新”被否定。

如果是 React 全栈应用：

Next.js

但 API 复杂后，要及时把后端边界拆出来。不要把所有业务都塞进页面框架里。

如果是后台管理系统、传统业务系统、CRUD 很多：

1	AdonisJS 或 NestJS

AdonisJS 更像完整后端框架，NestJS 更像企业应用骨架。两者都比裸 Express 更有秩序。

十二、最后说一句

Node.js 生态最大的问题不是框架太少，而是选择太多。

选择太多时，最容易犯的错就是每次都追最新、最快、最酷。

但真实项目里，框架最重要的能力往往不是 benchmark 第一，而是：

半年后还能不能维护。
新人来了能不能看懂。
线上出了问题能不能定位。
依赖升级会不会太痛。
业务复杂后结构会不会塌。

所以我的态度很简单：

小服务选轻的，团队项目选有约束的，页面驱动选全栈框架，边缘部署选 Web Standards，多年业务系统选能长期维护的。

不要为了框架而框架。

框架只是把项目带到生产环境的一种组织方式。选对了，它会帮你省心。选错了，它会在每一次需求变更时提醒你，当初那一点“看起来很爽”的自由，其实是有利息的。