数据核对：2026-10-22（GitHub API 实测）
先说结论
- 新项目、要长期维护 → NestJS（团队）或 Fastify（单人）
- 学教程、找现成代码 → Express，资料最多
- 部署到边缘运行时（Cloudflare Workers 等） → Hono
- 用 Bun 且要极致类型安全 → Elysia
Node.js 后端这三年的变化：Express 5 在 2024 年 9 月正式发布，这是它十年来第一个大版本、拿掉了 callback 时代的老包袱；Hono 和 Elysia 抢走了边缘计算场景，NestJS 在企业项目里站稳了。
一、五种设计取向
| 框架 | 设计取向 | 一句话 |
|---|---|---|
| Express | 极简，中间件链 | 老牌，什么都自己拼 |
| Fastify | 性能 + Schema | 用 JSON Schema 换速度和安全 |
| NestJS | 架构约定 | 像 Angular 的后端，装饰器 + 依赖注入 |
| Hono | 轻 + 跨运行时 | 同一套代码跑 Node/Deno/Bun/边缘 |
| Elysia | Bun 原生 + 类型 | 端到端类型推导 |
二、实测数据
| 框架 | star | 最新版本 |
|---|---|---|
| NestJS | 76,878 | 12.2.0 |
| Express | 69,575 | 5.3.0 |
| Fastify | 37,282 | 5.10.1 |
| Hono | 32,626 | 4.12.x |
| Elysia | 19,275 | 2.0 |
三、逐个说清
Express 5
生态最大的 Node 框架，几乎所有教程和中间件都是围绕它写的。
Express 5 修掉了几个长期痛点：async handler 里的 Promise 拒绝会被自动捕获（以前要手写 try/catch 或用包装函数），路径匹配语法也更规范了。
版本现状：5.0.0 发布于 2024-09-10，当前最新是 5.3.0（2026-10），要求 Node.js 18 及以上。官方不设固定 EOL，只维护当前大版本线，4.x 仍可用但不再推荐新项目采用。升级前需要留意两处破坏性变更：req.query 变成只读的简单解析器（不再支持写入），路径中的正则字符不再被支持、通配符必须写成命名形式（/*splat）。
代价：
- 设计停留在 2010 年代。没有内置的校验、没有依赖注入、没有目录约定
- 性能在中下水平（相比 Fastify/Hono）
- TypeScript 支持是靠
@types/express补的，不是原生
适合：维护老项目、需要大量现成中间件、快速出原型。
Fastify
核心是用 JSON Schema 定义请求和响应，换来两个好处：请求校验自动完成，序列化速度更快（它用 schema 编译出序列化函数，比 JSON.stringify 快）。
fastify.post('/users', {
schema: {
body: { type: 'object', required: ['name'],
properties: { name: { type: 'string' } } },
response: { 200: { type: 'object', properties: { id: { type: 'integer' } } } }
}
}, async (req) => ({ id: 1 }))
代价：写 schema 有额外工作量；插件系统（fastify.register）有封装规则，不熟悉的人容易踩「插件作用域」的坑。
适合：对吞吐量有要求的 API、愿意为性能多写点声明的团队。
NestJS
把 Angular 那套搬到后端：模块、控制器、服务、依赖注入、装饰器。
它解决的是「大型项目怎么组织」，不是「怎么跑得快」。团队超过 5 个人、项目要活几年，这套约定能省下大量争论。
代价：
- 重。学习曲线陡，不熟悉 DI 的人上手困难
- 抽象层多，出错时堆栈很长
- 一个简单接口要写 controller + service + module 三个文件
适合：企业级项目、多人协作、需要清晰分层。
不适合：小服务、脚本、API 网关这类轻量场景。
Hono
为边缘运行时设计：体积小（核心几 KB）、启动快、零依赖、同一套代码跑 Node / Deno / Bun / Cloudflare Workers / Vercel。
API 风格接近 Express，但用的是 Web 标准（Request / Response）。
代价：生态比 Express 小很多；Node.js 特有的能力（原生模块、复杂流处理）在边缘运行时里不可用。
适合：部署到边缘的 API、需要跨运行时的库、想冷启动快的 Serverless 函数。
Elysia
专为 Bun 设计，核心卖点是端到端类型推导：定义了 schema，handler 里的参数和返回值都有类型，不需要手写 TypeScript 接口。
代价：以 Bun 为首要运行时。Node 侧有官方适配器 @elysiajs/node（new Elysia({ adapter: node() })），但启动速度与 Bun 专属能力不及原生，生态里的插件也默认按 Bun 假设。
适合：新项目、已经用 Bun、追求类型安全。
四、按场景选
| 场景 | 推荐 |
|---|---|
| 团队项目、要活几年 | NestJS |
| 单人 / 小团队、要性能 | Fastify |
| 边缘部署 / Serverless | Hono |
| 维护老项目 / 快速原型 | Express 5 |
| 用 Bun 的新项目 | Elysia |
五、两个判断标准
① 先问「部署在哪」
如果目标是 Cloudflare Workers、Vercel Edge 这类环境，选择范围瞬间缩到 Hono。这类运行时没有完整的 Node API，Express、NestJS 都跑不了。
② 再问「团队几个人」
1-2 人：别用 NestJS，约定带来的收益抵不过学习成本。 5 人以上：值得用 NestJS，统一的结构能省下无数次「这个逻辑该放哪」的讨论。