Node.js 做服务端绕不开的一个问题就是框架选型。我这些年接手过不少项目有从零起步的也有中途接盘别人代码的Express、Koa2、Nest.js 这三个框架基本都深度用过。说实话每次有新项目要定技术栈团队里总会有人问一句用哪个然后就是一轮争论。有人觉得 Express 够用就行有人觉得 Koa2 优雅还有人坚持 Nest.js 才是正道。这些争论本身没有对错但如果选错了后面维护起来是真的难受。这篇文章我想把这三个框架从底层设计到实际项目落地掰开揉碎讲一遍。不是那种官方文档式的 API 罗列而是从为什么这么设计什么场景该用哪个踩过哪些坑的角度来聊。如果你正在做技术选型或者刚接手一个 Node.js 服务端项目需要快速理解现有架构再或者你只是想知道这三个框架到底差在哪这篇内容应该能帮你省下不少查资料和试错的时间。1. 三个框架的出身决定了它们的性格选框架这件事跟看人有点像。一个人的出身和成长经历决定了他的性格底色框架也一样。Express、Koa2、Nest.js 这三个虽然都跑在 Node.js 上但它们诞生的时间、要解决的问题、背后的设计哲学完全不同。搞清楚这些你才能理解为什么它们的写法差异那么大。1.1 Express先来者定义了什么是 Node.js Web 框架Express 最早发布于 2010 年那会儿 Node.js 本身也才刚出来没多久。当时大家对用 JavaScript 写服务端这件事还很陌生Express 的出现 basically 定义了后来者对 Node.js Web 框架的基本认知中间件模型、路由系统、请求响应对象的扩展。它的核心设计思路非常朴素——一切皆中间件。一个请求进来经过一层一层的中间件处理每层可以选择处理完就返回也可以调用next()交给下一层。这个模型简单到什么程度呢你甚至可以在脑子里画出一条直线请求从左边进去从右边出来中间经过的每一站就是一个中间件。const express require(express); const app express(); app.use((req, res, next) { console.log(第一个中间件); next(); }); app.get(/users, (req, res) { res.json({ users: [] }); }); app.listen(3000);这种设计的优点是直观、好理解、上手快。但缺点也很明显中间件的执行顺序完全靠代码书写顺序来决定当项目变大、中间件多到几十个的时候调试起来就很痛苦。你很难一眼看出一个请求到底经过了哪些处理步骤。Express 另一个特点是它对 Node.js 原生req和res对象做了大量扩展。比如res.json()、res.send()、req.params、req.query这些都是 Express 加上去的。好处是写起来方便坏处是这些扩展跟原生对象混在一起时间长了容易搞不清楚哪些是原生的、哪些是框架加的。1.2 Koa2把中间件模型做了一次重构Koa 是 Express 原班人马在 2013 年左右搞出来的Koa2 则是全面拥抱 async/await 之后的版本。它的核心思路是Express 的中间件模型是对的但实现方式可以更优雅。Koa2 最大的变化是引入了洋葱模型。什么意思呢中间件不再是简单的进去、处理、出来而是可以分成请求阶段和响应阶段两部分。代码写起来是这样的const Koa require(koa); const app new Koa(); app.use(async (ctx, next) { console.log(进入第一层 - 请求阶段); await next(); console.log(离开第一层 - 响应阶段); }); app.use(async (ctx, next) { console.log(进入第二层 - 请求阶段); await next(); console.log(离开第二层 - 响应阶段); });执行顺序是第一层请求阶段 → 第二层请求阶段 → 第二层响应阶段 → 第一层响应阶段。像洋葱一样一层层剥进去再一层层出来。这个模型的好处是你可以在await next()之前做请求预处理在之后做响应后处理逻辑非常清晰。比如你想统计每个请求的处理耗时在 Koa2 里写起来就很自然app.use(async (ctx, next) { const start Date.now(); await next(); const ms Date.now() - start; ctx.set(X-Response-Time, ${ms}ms); });Koa2 另一个重要特点是它不内置路由、不内置 body 解析、不内置任何额外的东西。核心代码非常精简你需要什么就自己装什么中间件。这种极简内核 生态中间件的思路好处是灵活、可控坏处是新手上来会有点懵——怎么连路由都要自己装1.3 Nest.js把后端工程的规矩带进了 Node.jsNest.js 是 2017 年出现的它的设计灵感主要来自 Angular。如果你之前写过 Angular 或者 Java 的 Spring看 Nest.js 的代码会有一种莫名的熟悉感装饰器、依赖注入、模块化、分层架构这些在企业级后端开发中常见的概念Nest.js 全都给你安排上了。Controller(users) export class UsersController { constructor(private readonly usersService: UsersService) {} Get() findAll(): PromiseUser[] { return this.usersService.findAll(); } }Nest.js 默认使用 TypeScript这一点很关键。它不只是支持 TypeScript而是整个框架的设计就是围绕 TypeScript 来的。装饰器语法、类型系统、依赖注入容器这些都需要 TypeScript 才能发挥最大价值。它的核心设计目标是解决一个问题当 Node.js 项目变大之后代码怎么组织才不会乱Express 和 Koa2 都没有给出强约束你可以把路由、业务逻辑、数据访问全写在一个文件里也可以分得很细。Nest.js 则通过模块系统、控制器、服务、提供者这些概念强制你把代码分层。这种强约束的好处是团队协作时大家写的代码风格会比较统一新人接手也容易理解。坏处是学习曲线明显更陡你得先理解依赖注入、模块、装饰器这些概念才能开始写业务代码。2. 请求处理链路的底层差异三个框架在一个请求进来之后到底发生了什么这件事上差异比表面看起来要大得多。理解这些差异能帮你在遇到性能问题或者诡异 bug 的时候快速定位到根因。2.1 Express 的线性中间件栈Express 的中间件本质上是一个数组请求进来之后从数组的第一个元素开始依次执行。每个中间件函数接收(req, res, next)三个参数调用next()就继续往下走不调用就停在那里。这个模型有一个容易被忽略的细节Express 不关心你的中间件是同步还是异步的。如果你在中间件里写了异步操作但忘了处理错误错误就会悄无声息地消失。比如app.use(async (req, res, next) { const data await someAsyncOperation(); // 如果这里抛错了 next(); // 这行不会执行错误也不会被 Express 捕获 });这是 Express 在实际项目中最常见的坑之一。因为 Express 的中间件机制是在 async/await 普及之前设计的它只认同步抛出的错误。异步操作抛出的错误需要你手动try/catch然后next(err)传给错误处理中间件。Express 5.x 对这一点做了一些改进开始支持返回 Promise 的中间件自动捕获错误但很多现有项目还在用 4.x所以这个问题依然普遍存在。2.2 Koa2 的洋葱模型与错误冒泡Koa2 的中间件执行机制跟 Express 有本质区别。它使用async/await来串联中间件每个中间件都是一个 async 函数await next()会等待后续所有中间件执行完毕。这个设计带来的一个直接好处是错误处理变得非常自然。因为await next()本身就在 try/catch 的作用域内任何下游中间件抛出的错误都会沿着调用链向上冒泡app.use(async (ctx, next) { try { await next(); } catch (err) { ctx.status err.status || 500; ctx.body { message: err.message }; } });这段代码放在最外层就能捕获所有下游中间件的错误包括异步操作中的错误。不需要像 Express 那样在每个中间件里手动 try/catch。但洋葱模型也有它的代价。因为await next()会等待所有下游完成如果你在请求阶段做了某些操作比如开启数据库事务然后在响应阶段提交那么整个请求的耗时会被拉长。而且如果下游某个中间件卡住了上游的响应阶段代码就永远执行不到。2.3 Nest.js 的请求生命周期Nest.js 的请求处理链路比前两者复杂得多因为它引入了中间件、守卫、拦截器、管道、异常过滤器这一整套概念。一个请求进来大致要经过这么几个阶段中间件Middleware跟 Express 的中间件类似最外层守卫Guard决定请求是否被允许通过常用于权限校验拦截器Interceptor在方法执行前后插入逻辑常用于日志、缓存、响应转换管道Pipe对请求参数进行转换和校验控制器方法Controller Method实际的业务处理异常过滤器Exception Filter捕获并处理异常这套机制的好处是职责分离非常清晰。权限校验就写在守卫里参数校验就写在管道里日志就写在拦截器里各司其职。坏处是链路太长一个请求要经过这么多层性能开销比 Express 和 Koa2 要大。而且调试的时候你得清楚每个阶段发生了什么不然容易懵。我实测过一个简单的接口在同样的硬件条件下Express 的 QPS 大概在 8000 左右Koa2 差不多Nest.js 大概在 5000 到 6000 之间。当然这个数字跟具体业务逻辑关系很大只是一个粗略的参考。如果你的项目对性能极其敏感这一点需要纳入考虑。3. 项目结构从自由到约束的光谱项目结构这件事在小项目里可能感觉不到差别但项目一旦超过一定规模结构的好坏直接影响维护成本。三个框架在这一点上恰好代表了从完全自由到强约束的三个点。3.1 Express 项目的结构全靠自觉Express 本身不规定你怎么组织代码。你可以把所有路由写在一个app.js里也可以用express.Router()拆分成多个文件。官方文档给的建议也很简单用 Router 分模块。实际项目中一个典型的 Express 项目结构大概是这样project/ ├── app.js ├── routes/ │ ├── users.js │ └── orders.js ├── controllers/ │ ├── userController.js │ └── orderController.js ├── services/ │ ├── userService.js │ └── orderService.js ├── models/ │ ├── user.js │ └── order.js └── middlewares/ └── auth.js这个结构看起来挺清晰但问题是没有任何机制强制你这么做。我见过太多 Express 项目写着写着业务逻辑就跑到路由文件里去了数据库操作也直接写在控制器里service 层形同虚设。时间一长代码就变成了一锅粥。Express 项目要保持结构清晰完全依赖团队的自律和 code review。如果团队里有人不守规矩或者项目赶工期结构很快就会崩坏。3.2 Koa2 的结构更依赖生态约定Koa2 比 Express 更裸它连路由都不内置。所以 Koa2 项目的结构很大程度上取决于你选了哪些中间件和工具。一个常见的 Koa2 项目结构project/ ├── app.js ├── router/ │ ├── index.js │ └── users.js ├── controller/ │ └── userController.js ├── service/ │ └── userService.js ├── middleware/ │ └── errorHandler.js └── config/ └── default.js跟 Express 项目差不多但 Koa2 社区有一些约定俗成的做法比如用koa-router做路由、用koa-bodyparser解析请求体、用koa-views渲染模板。这些中间件的选择本身就会影响项目结构。Koa2 项目的一个典型问题是中间件的顺序很关键。比如错误处理中间件必须放在最前面body 解析中间件必须放在路由之前。如果顺序搞错了就会出现各种奇怪的问题。这一点在项目结构文档里如果不写清楚新人很容易踩坑。3.3 Nest.js 用模块系统强制分层Nest.js 的项目结构是框架强制的。每个功能模块都是一个独立的 ModuleModule 里面包含 Controller、Service、Provider 等。一个典型的 Nest.js 项目结构src/ ├── app.module.ts ├── main.ts ├── users/ │ ├── users.module.ts │ ├── users.controller.ts │ ├── users.service.ts │ └── dto/ │ └── create-user.dto.ts └── orders/ ├── orders.module.ts ├── orders.controller.ts └── orders.service.ts这种结构的好处是每个模块的边界非常清晰。你要找用户相关的代码直接进users目录就行所有相关文件都在里面。模块之间通过依赖注入来协作耦合度低。但 Nest.js 的模块系统也有它的复杂性。比如循环依赖的问题两个模块互相引用对方的 Service就会报错。解决方法是使用forwardRef但这个东西用起来有点绕新手容易搞不明白。另外Nest.js 的模块划分粒度也需要经验。分得太细模块之间跳来跳去很累分得太粗又失去了模块化的意义。我个人的经验是按照业务领域来划分模块一个模块对应一个相对独立的业务能力比如用户模块、订单模块、支付模块。4. 错误处理与异步流程控制的实战差异错误处理是服务端开发中最容易被低估的部分。很多项目在正常流程下跑得好好的一遇到异常就各种问题。三个框架在错误处理上的差异直接影响了代码的健壮性。4.1 Express 的异步错误陷阱前面提到过Express 4.x 不会自动捕获异步中间件中的错误。这意味着如果你写了这样的代码app.get(/user/:id, async (req, res) { const user await User.findById(req.params.id); if (!user) { throw new Error(User not found); // 这个错误不会被 Express 捕获 } res.json(user); });当用户不存在时throw new Error抛出的错误不会被 Express 的错误处理中间件捕获请求会一直挂起直到超时。这是 Express 项目中最常见的 bug 之一。解决方案有几种。最简单的是在每个 async 函数里手动 try/catchapp.get(/user/:id, async (req, res, next) { try { const user await User.findById(req.params.id); if (!user) { throw new Error(User not found); } res.json(user); } catch (err) { next(err); } });但这样写太啰嗦了。更好的做法是封装一个asyncHandler高阶函数const asyncHandler (fn) (req, res, next) { Promise.resolve(fn(req, res, next)).catch(next); }; app.get(/user/:id, asyncHandler(async (req, res) { const user await User.findById(req.params.id); if (!user) { throw new Error(User not found); } res.json(user); }));这个模式在 Express 社区非常常见基本上每个 Express 项目都会用到。如果你在用 Express 5.x这个问题已经被框架层面解决了但 4.x 的项目还是得自己处理。4.2 Koa2 的错误处理更自然但要注意顺序Koa2 因为原生支持 async/await错误处理写起来自然得多。你只需要在最外层加一个 try/catch 中间件app.use(async (ctx, next) { try { await next(); } catch (err) { ctx.status err.statusCode || err.status || 500; ctx.body { code: ctx.status, message: err.message }; ctx.app.emit(error, err, ctx); } });但这里有一个关键点这个错误处理中间件必须放在所有中间件的最前面。因为 Koa2 的中间件是洋葱模型只有放在最外层才能捕获到所有内层中间件的错误。如果顺序放错了某些中间件的错误就捕获不到。另外Koa2 的ctx.throw()方法很好用可以抛出带有状态码的错误ctx.throw(401, 未授权访问);这个错误会被上面的错误处理中间件捕获然后返回 401 状态码和对应的消息。比手动设置ctx.status和ctx.body要方便。4.3 Nest.js 的异常过滤器体系Nest.js 有一套完整的异常处理机制。框架内置了HttpException类你可以直接抛出throw new NotFoundException(用户不存在);Nest.js 会自动把这个异常转换成对应的 HTTP 响应。除了内置的异常类你还可以自定义异常过滤器来处理特定类型的异常Catch(HttpException) export class HttpExceptionFilter implements ExceptionFilter { catch(exception: HttpException, host: ArgumentsHost) { const ctx host.switchToHttp(); const response ctx.getResponse(); const status exception.getStatus(); response.status(status).json({ code: status, message: exception.message, timestamp: new Date().toISOString() }); } }然后在全局或者控制器级别注册这个过滤器。这套机制的好处是异常处理逻辑可以集中管理不同模块可以有不同的异常处理策略。坏处是概念比较多需要花时间理解。Nest.js 还有一个容易被忽略的点默认情况下未捕获的异常会返回 500 错误但不会记录详细的错误信息。如果你不配置日志出了问题很难排查。所以生产环境中一定要配置好异常过滤器和日志系统。5. 生态与中间件选型的实际考量框架本身只是一部分真正决定开发效率的是围绕框架的生态系统。三个框架在这方面的差异也很大。5.1 Express 的生态最成熟但质量参差不齐Express 因为出现最早生态是最成熟的。基本上你能想到的功能都有对应的中间件。比如passport认证multer文件上传cors跨域处理helmet安全头设置morgan日志但问题是这些中间件的质量参差不齐。有些中间件已经很久没维护了有些中间件的文档写得很差还有些中间件之间有兼容性问题。我在实际项目中就遇到过passport和某个 JWT 中间件冲突的情况排查了大半天才发现是版本不兼容。另外Express 的中间件生态有一个历史遗留问题很多中间件还在用回调风格跟 async/await 混用的时候容易出问题。虽然大部分常用中间件都已经支持 Promise 了但偶尔还是会踩到坑。5.2 Koa2 的生态更精致但选择更少Koa2 的生态比 Express 小但整体质量更高。因为 Koa2 的中间件必须用 async/await 写所以风格比较统一。常用的中间件包括koa-router路由koa-bodyparser请求体解析koa-static静态文件服务koa-session会话管理koa-jwtJWT 认证Koa2 生态的一个特点是很多中间件都是官方出品或者官方推荐的比如koa-router、koa-bodyparser这些维护得都比较好。但 Koa2 的生态也有一个问题选择太少。比如你想找一个功能比较全的权限管理中间件Express 那边有好几个选择Koa2 这边可能就一两个而且不一定完全符合你的需求。这时候就得自己写或者从 Express 的中间件移植过来。5.3 Nest.js 的生态自成体系Nest.js 的生态跟 Express 和 Koa2 不太一样。它不是靠第三方中间件来扩展功能而是框架本身就提供了大部分企业级开发需要的能力。比如nestjs/typeorm数据库 ORM 集成nestjs/graphqlGraphQL 支持nestjs/microservices微服务支持nestjs/swaggerAPI 文档nestjs/config配置管理这些官方包的质量都很高文档也写得好。而且它们之间的集成非常顺畅比如你用nestjs/typeorm定义了实体nestjs/swagger就能自动生成对应的 API 文档。Nest.js 生态的另一个特点是它底层可以跑在 Express 或 Fastify 上。默认是 Express但你可以通过配置切换到 Fastify获得更好的性能。这个设计很聪明既利用了 Express 成熟的生态又给了性能优化的空间。但 Nest.js 的生态也有一个缺点学习成本高。每个官方包都有自己的概念和用法你得花时间一个个学。而且 Nest.js 的版本更新比较快有时候升级版本会遇到 breaking change需要花时间适配。6. 性能表现与适用场景的匹配性能这个话题很容易引起争论因为测试条件不同结果差异很大。我这里不打算给出绝对的结论而是从实际项目经验出发聊聊三个框架在性能上的特点和适用场景。6.1 基准测试的参考价值有限网上有很多三个框架的性能对比测试但说实话这些测试的参考价值有限。因为测试用的业务逻辑通常很简单跟真实项目差距大硬件环境、Node.js 版本、测试工具都会影响结果框架的性能瓶颈往往不在框架本身而在数据库查询、外部 API 调用等我自己的经验是在简单的 CRUD 场景下Express 和 Koa2 的性能差不多Nest.js 大概低 20% 到 30%。但在复杂的业务场景下这个差距会被数据库操作、业务逻辑计算等稀释实际感受不明显。6.2 不同规模项目的选型建议根据我这些年做项目的经验三个框架的适用场景大致可以这样划分项目规模推荐框架理由小型项目、原型验证Express上手快生态全随便怎么写都能跑中型项目、API 服务Koa2结构清晰中间件模型优雅性能好大型项目、企业级应用Nest.js强约束分层清晰适合团队协作需要快速迭代的创业项目Express 或 Koa2灵活改起来快不用被框架约束长期维护的核心系统Nest.js结构稳定新人接手成本低当然这只是一个大致的参考。实际选型还要考虑团队的技术栈、项目的生命周期、性能要求等因素。6.3 我踩过的选型坑说几个我实际踩过的坑希望能帮你避开。第一个坑是用 Express 写大型项目。我接手过一个 Express 项目代码量大概几万行路由文件有几十个中间件嵌套了七八层。每次改一个功能都要花很长时间理清请求链路。后来实在受不了花了两周时间重构成了 Nest.js虽然重构过程很痛苦但之后维护效率明显提升。第二个坑是用 Nest.js 写小项目。有一次做一个内部工具功能很简单就几个接口。我想着用 Nest.js 规范一点结果光是搭项目结构、配置模块就花了大半天。后来想想这种项目用 Express 半小时就能搞定。第三个坑是Koa2 中间件顺序搞错。Koa2 的中间件顺序非常关键我有一次把日志中间件放在了错误处理中间件前面结果错误发生的时候日志中间件已经执行完了错误信息没记录到日志里。排查了半天才发现是顺序问题。7. 从 Express 迁移到 Nest.js 的实操经验如果你正在考虑从 Express 迁移到 Nest.js或者想了解迁移过程中会遇到什么问题这一节的内容应该对你有帮助。我完整经历过一次迁移把一些关键点整理出来。7.1 迁移前的评估不是所有项目都值得迁移迁移框架是一件成本很高的事情不是所有项目都值得做。我建议你先评估几个问题项目是否还在活跃开发如果已经进入维护期迁移的收益不大团队是否愿意学习新框架Nest.js 的学习曲线不低项目是否有结构混乱的问题如果 Express 项目结构本来就清晰迁移的必要性不大是否有足够的测试覆盖没有测试的迁移风险极高我迁移的那个项目是因为结构已经乱到影响开发效率了而且团队里有人用过 Nest.js学习成本可控。如果你的项目没有这些问题建议先优化现有代码而不是急着换框架。7.2 迁移策略渐进式还是重写迁移策略有两种渐进式迁移和完全重写。渐进式迁移是指在现有 Express 项目中逐步引入 Nest.js比如先把某个模块用 Nest.js 重写然后通过某种方式让两个框架共存。这种方式的优点是风险低可以边迁移边验证。缺点是配置复杂两个框架的中间件、错误处理机制需要打通。完全重写是指用 Nest.js 重新实现整个项目。优点是干净彻底没有历史包袱。缺点是风险高周期长而且重写过程中可能会有功能遗漏。我选择的是完全重写因为项目本身不算太大而且渐进式迁移的配置成本太高。重写过程中我先把 Express 的路由和控制器逻辑梳理清楚然后按照 Nest.js 的模块划分重新组织。数据库层基本没动因为用的是 TypeORMNest.js 也有对应的集成包。7.3 迁移中的具体问题与解决迁移过程中遇到了几个具体问题这里列出来供参考。第一个问题是中间件的迁移。Express 的中间件在 Nest.js 里对应的是 Middleware但用法不太一样。Nest.js 的中间件需要实现NestMiddleware接口而且要在模块里注册。一些 Express 的中间件可以直接用比如cors、helmet但有些需要改写。第二个问题是错误处理的迁移。Express 的错误处理中间件在 Nest.js 里对应的是 ExceptionFilter。Nest.js 的异常过滤器功能更强但写法完全不同。我花了一些时间把原来的错误处理逻辑重写成过滤器。第三个问题是依赖注入的引入。Express 项目里通常是手动 require 模块Nest.js 则通过依赖注入来管理。刚开始不太习惯但用久了会发现依赖注入确实让代码更清晰尤其是写单元测试的时候mock 依赖很方便。第四个问题是 TypeScript 的类型定义。Nest.js 默认用 TypeScript所以迁移过程中需要给原来的 JavaScript 代码加上类型定义。这个过程比较繁琐但加完之后代码的可维护性确实提升了。8. 三个框架的长期维护成本对比选框架不能只看开发效率还要看长期维护成本。一个项目上线之后可能要维护好几年维护成本往往比开发成本更高。8.1 代码可读性与新人上手成本从代码可读性来看Nest.js 是最好的。因为它的结构强制分层新人接手的时候只要理解了模块、控制器、服务这几个概念就能快速定位到相关代码。而且 TypeScript 的类型系统本身就是一种文档能帮新人理解数据结构。Express 和 Koa2 的可读性取决于团队的编码规范。如果团队规范执行得好代码也可以很清晰。但如果规范执行不到位代码就会很乱。我见过一个 Express 项目路由、业务逻辑、数据库操作全写在一个文件里一个文件几千行新人根本不敢改。8.2 依赖升级与安全补丁从依赖升级的角度看Express 和 Koa2 的升级相对简单因为它们的核心 API 比较稳定。Express 4.x 已经很多年没大版本更新了Koa2 的 API 也很稳定。Nest.js 的版本更新比较快而且有时候会有 breaking change。比如从 Nest.js 8 升级到 9一些 API 发生了变化需要改代码。但 Nest.js 的升级文档写得很好按照文档一步步来问题不大。安全补丁方面三个框架都有活跃的社区在维护发现安全问题后都会及时修复。但 Nest.js 因为依赖比较多需要关注的依赖也更多。建议使用npm audit或者snyk定期检查依赖的安全性。8.3 社区活跃度与问题解决效率从社区活跃度来看Express 的社区最大遇到问题基本都能搜到答案。但因为 Express 出现得早很多答案可能已经过时了需要注意甄别。Koa2 的社区比 Express 小但核心贡献者比较活跃GitHub 上的 issue 响应速度还可以。Nest.js 的社区虽然相对较小但增长很快而且官方文档非常详细。大部分问题都能在官方文档里找到答案。另外 Nest.js 的 Discord 社区也很活跃遇到问题可以在上面提问。9. 我的选型决策框架聊了这么多最后分享一下我自己的选型决策框架。每次有新项目要定框架我都会按这个框架过一遍。9.1 先问三个问题第一个问题项目预期寿命有多长如果只是做个原型或者临时工具用 Express 快速搞定就行。如果是要长期维护的核心系统Nest.js 更合适。第二个问题团队的技术背景是什么如果团队都是前端转过来的对 TypeScript 和装饰器比较熟悉Nest.js 上手会快一些。如果团队以前主要写 Java 或者 C#Nest.js 的依赖注入和分层架构会让他们感觉很亲切。如果团队都是 JavaScript 老手Express 或 Koa2 可能更顺手。第三个问题项目的性能要求有多高如果 QPS 要求很高Koa2 或者 Express Fastify 可能更合适。如果性能要求一般Nest.js 完全够用。9.2 我的默认选择如果让我给一个默认建议我会说不确定选什么的时候选 Express。它不会让你惊艳但也不会让你踩大坑。生态成熟遇到问题好解决。想要更优雅的代码结构选 Koa2。它的中间件模型确实比 Express 舒服但需要你对 async/await 有比较深的理解。团队协作、长期维护的项目选 Nest.js。前期学习成本高但后期维护成本低。9.3 一个反直觉的建议最后说一个可能有点反直觉的建议不要因为性能而选框架。我见过太多团队为了追求所谓的性能选了某个框架结果项目上线后发现瓶颈根本不在框架而在数据库查询或者外部 API 调用。框架的性能差异在大多数业务场景下是可以忽略的。真正影响性能的是你的数据库设计、缓存策略、代码质量。与其纠结框架的性能不如花时间优化这些方面。当然如果你的项目确实是性能敏感型的比如做实时通信、高频交易之类的那框架的性能就很重要了。但这种场景下你可能需要考虑的更底层的东西比如直接用 Node.js 的http模块或者用更专业的框架。选框架这件事没有标准答案。重要的是理解每个框架的设计哲学和适用场景然后根据你的具体情况做决策。希望这篇内容能帮你理清思路做出适合自己的选择。 Express、Koa2、Nest.js 三大 Node.js 框架深度对比与选型指南
Node.js 做服务端绕不开的一个问题就是框架选型。我这些年接手过不少项目有从零起步的也有中途接盘别人代码的Express、Koa2、Nest.js 这三个框架基本都深度用过。说实话每次有新项目要定技术栈团队里总会有人问一句用哪个然后就是一轮争论。有人觉得 Express 够用就行有人觉得 Koa2 优雅还有人坚持 Nest.js 才是正道。这些争论本身没有对错但如果选错了后面维护起来是真的难受。这篇文章我想把这三个框架从底层设计到实际项目落地掰开揉碎讲一遍。不是那种官方文档式的 API 罗列而是从为什么这么设计什么场景该用哪个踩过哪些坑的角度来聊。如果你正在做技术选型或者刚接手一个 Node.js 服务端项目需要快速理解现有架构再或者你只是想知道这三个框架到底差在哪这篇内容应该能帮你省下不少查资料和试错的时间。1. 三个框架的出身决定了它们的性格选框架这件事跟看人有点像。一个人的出身和成长经历决定了他的性格底色框架也一样。Express、Koa2、Nest.js 这三个虽然都跑在 Node.js 上但它们诞生的时间、要解决的问题、背后的设计哲学完全不同。搞清楚这些你才能理解为什么它们的写法差异那么大。1.1 Express先来者定义了什么是 Node.js Web 框架Express 最早发布于 2010 年那会儿 Node.js 本身也才刚出来没多久。当时大家对用 JavaScript 写服务端这件事还很陌生Express 的出现 basically 定义了后来者对 Node.js Web 框架的基本认知中间件模型、路由系统、请求响应对象的扩展。它的核心设计思路非常朴素——一切皆中间件。一个请求进来经过一层一层的中间件处理每层可以选择处理完就返回也可以调用next()交给下一层。这个模型简单到什么程度呢你甚至可以在脑子里画出一条直线请求从左边进去从右边出来中间经过的每一站就是一个中间件。const express require(express); const app express(); app.use((req, res, next) { console.log(第一个中间件); next(); }); app.get(/users, (req, res) { res.json({ users: [] }); }); app.listen(3000);这种设计的优点是直观、好理解、上手快。但缺点也很明显中间件的执行顺序完全靠代码书写顺序来决定当项目变大、中间件多到几十个的时候调试起来就很痛苦。你很难一眼看出一个请求到底经过了哪些处理步骤。Express 另一个特点是它对 Node.js 原生req和res对象做了大量扩展。比如res.json()、res.send()、req.params、req.query这些都是 Express 加上去的。好处是写起来方便坏处是这些扩展跟原生对象混在一起时间长了容易搞不清楚哪些是原生的、哪些是框架加的。1.2 Koa2把中间件模型做了一次重构Koa 是 Express 原班人马在 2013 年左右搞出来的Koa2 则是全面拥抱 async/await 之后的版本。它的核心思路是Express 的中间件模型是对的但实现方式可以更优雅。Koa2 最大的变化是引入了洋葱模型。什么意思呢中间件不再是简单的进去、处理、出来而是可以分成请求阶段和响应阶段两部分。代码写起来是这样的const Koa require(koa); const app new Koa(); app.use(async (ctx, next) { console.log(进入第一层 - 请求阶段); await next(); console.log(离开第一层 - 响应阶段); }); app.use(async (ctx, next) { console.log(进入第二层 - 请求阶段); await next(); console.log(离开第二层 - 响应阶段); });执行顺序是第一层请求阶段 → 第二层请求阶段 → 第二层响应阶段 → 第一层响应阶段。像洋葱一样一层层剥进去再一层层出来。这个模型的好处是你可以在await next()之前做请求预处理在之后做响应后处理逻辑非常清晰。比如你想统计每个请求的处理耗时在 Koa2 里写起来就很自然app.use(async (ctx, next) { const start Date.now(); await next(); const ms Date.now() - start; ctx.set(X-Response-Time, ${ms}ms); });Koa2 另一个重要特点是它不内置路由、不内置 body 解析、不内置任何额外的东西。核心代码非常精简你需要什么就自己装什么中间件。这种极简内核 生态中间件的思路好处是灵活、可控坏处是新手上来会有点懵——怎么连路由都要自己装1.3 Nest.js把后端工程的规矩带进了 Node.jsNest.js 是 2017 年出现的它的设计灵感主要来自 Angular。如果你之前写过 Angular 或者 Java 的 Spring看 Nest.js 的代码会有一种莫名的熟悉感装饰器、依赖注入、模块化、分层架构这些在企业级后端开发中常见的概念Nest.js 全都给你安排上了。Controller(users) export class UsersController { constructor(private readonly usersService: UsersService) {} Get() findAll(): PromiseUser[] { return this.usersService.findAll(); } }Nest.js 默认使用 TypeScript这一点很关键。它不只是支持 TypeScript而是整个框架的设计就是围绕 TypeScript 来的。装饰器语法、类型系统、依赖注入容器这些都需要 TypeScript 才能发挥最大价值。它的核心设计目标是解决一个问题当 Node.js 项目变大之后代码怎么组织才不会乱Express 和 Koa2 都没有给出强约束你可以把路由、业务逻辑、数据访问全写在一个文件里也可以分得很细。Nest.js 则通过模块系统、控制器、服务、提供者这些概念强制你把代码分层。这种强约束的好处是团队协作时大家写的代码风格会比较统一新人接手也容易理解。坏处是学习曲线明显更陡你得先理解依赖注入、模块、装饰器这些概念才能开始写业务代码。2. 请求处理链路的底层差异三个框架在一个请求进来之后到底发生了什么这件事上差异比表面看起来要大得多。理解这些差异能帮你在遇到性能问题或者诡异 bug 的时候快速定位到根因。2.1 Express 的线性中间件栈Express 的中间件本质上是一个数组请求进来之后从数组的第一个元素开始依次执行。每个中间件函数接收(req, res, next)三个参数调用next()就继续往下走不调用就停在那里。这个模型有一个容易被忽略的细节Express 不关心你的中间件是同步还是异步的。如果你在中间件里写了异步操作但忘了处理错误错误就会悄无声息地消失。比如app.use(async (req, res, next) { const data await someAsyncOperation(); // 如果这里抛错了 next(); // 这行不会执行错误也不会被 Express 捕获 });这是 Express 在实际项目中最常见的坑之一。因为 Express 的中间件机制是在 async/await 普及之前设计的它只认同步抛出的错误。异步操作抛出的错误需要你手动try/catch然后next(err)传给错误处理中间件。Express 5.x 对这一点做了一些改进开始支持返回 Promise 的中间件自动捕获错误但很多现有项目还在用 4.x所以这个问题依然普遍存在。2.2 Koa2 的洋葱模型与错误冒泡Koa2 的中间件执行机制跟 Express 有本质区别。它使用async/await来串联中间件每个中间件都是一个 async 函数await next()会等待后续所有中间件执行完毕。这个设计带来的一个直接好处是错误处理变得非常自然。因为await next()本身就在 try/catch 的作用域内任何下游中间件抛出的错误都会沿着调用链向上冒泡app.use(async (ctx, next) { try { await next(); } catch (err) { ctx.status err.status || 500; ctx.body { message: err.message }; } });这段代码放在最外层就能捕获所有下游中间件的错误包括异步操作中的错误。不需要像 Express 那样在每个中间件里手动 try/catch。但洋葱模型也有它的代价。因为await next()会等待所有下游完成如果你在请求阶段做了某些操作比如开启数据库事务然后在响应阶段提交那么整个请求的耗时会被拉长。而且如果下游某个中间件卡住了上游的响应阶段代码就永远执行不到。2.3 Nest.js 的请求生命周期Nest.js 的请求处理链路比前两者复杂得多因为它引入了中间件、守卫、拦截器、管道、异常过滤器这一整套概念。一个请求进来大致要经过这么几个阶段中间件Middleware跟 Express 的中间件类似最外层守卫Guard决定请求是否被允许通过常用于权限校验拦截器Interceptor在方法执行前后插入逻辑常用于日志、缓存、响应转换管道Pipe对请求参数进行转换和校验控制器方法Controller Method实际的业务处理异常过滤器Exception Filter捕获并处理异常这套机制的好处是职责分离非常清晰。权限校验就写在守卫里参数校验就写在管道里日志就写在拦截器里各司其职。坏处是链路太长一个请求要经过这么多层性能开销比 Express 和 Koa2 要大。而且调试的时候你得清楚每个阶段发生了什么不然容易懵。我实测过一个简单的接口在同样的硬件条件下Express 的 QPS 大概在 8000 左右Koa2 差不多Nest.js 大概在 5000 到 6000 之间。当然这个数字跟具体业务逻辑关系很大只是一个粗略的参考。如果你的项目对性能极其敏感这一点需要纳入考虑。3. 项目结构从自由到约束的光谱项目结构这件事在小项目里可能感觉不到差别但项目一旦超过一定规模结构的好坏直接影响维护成本。三个框架在这一点上恰好代表了从完全自由到强约束的三个点。3.1 Express 项目的结构全靠自觉Express 本身不规定你怎么组织代码。你可以把所有路由写在一个app.js里也可以用express.Router()拆分成多个文件。官方文档给的建议也很简单用 Router 分模块。实际项目中一个典型的 Express 项目结构大概是这样project/ ├── app.js ├── routes/ │ ├── users.js │ └── orders.js ├── controllers/ │ ├── userController.js │ └── orderController.js ├── services/ │ ├── userService.js │ └── orderService.js ├── models/ │ ├── user.js │ └── order.js └── middlewares/ └── auth.js这个结构看起来挺清晰但问题是没有任何机制强制你这么做。我见过太多 Express 项目写着写着业务逻辑就跑到路由文件里去了数据库操作也直接写在控制器里service 层形同虚设。时间一长代码就变成了一锅粥。Express 项目要保持结构清晰完全依赖团队的自律和 code review。如果团队里有人不守规矩或者项目赶工期结构很快就会崩坏。3.2 Koa2 的结构更依赖生态约定Koa2 比 Express 更裸它连路由都不内置。所以 Koa2 项目的结构很大程度上取决于你选了哪些中间件和工具。一个常见的 Koa2 项目结构project/ ├── app.js ├── router/ │ ├── index.js │ └── users.js ├── controller/ │ └── userController.js ├── service/ │ └── userService.js ├── middleware/ │ └── errorHandler.js └── config/ └── default.js跟 Express 项目差不多但 Koa2 社区有一些约定俗成的做法比如用koa-router做路由、用koa-bodyparser解析请求体、用koa-views渲染模板。这些中间件的选择本身就会影响项目结构。Koa2 项目的一个典型问题是中间件的顺序很关键。比如错误处理中间件必须放在最前面body 解析中间件必须放在路由之前。如果顺序搞错了就会出现各种奇怪的问题。这一点在项目结构文档里如果不写清楚新人很容易踩坑。3.3 Nest.js 用模块系统强制分层Nest.js 的项目结构是框架强制的。每个功能模块都是一个独立的 ModuleModule 里面包含 Controller、Service、Provider 等。一个典型的 Nest.js 项目结构src/ ├── app.module.ts ├── main.ts ├── users/ │ ├── users.module.ts │ ├── users.controller.ts │ ├── users.service.ts │ └── dto/ │ └── create-user.dto.ts └── orders/ ├── orders.module.ts ├── orders.controller.ts └── orders.service.ts这种结构的好处是每个模块的边界非常清晰。你要找用户相关的代码直接进users目录就行所有相关文件都在里面。模块之间通过依赖注入来协作耦合度低。但 Nest.js 的模块系统也有它的复杂性。比如循环依赖的问题两个模块互相引用对方的 Service就会报错。解决方法是使用forwardRef但这个东西用起来有点绕新手容易搞不明白。另外Nest.js 的模块划分粒度也需要经验。分得太细模块之间跳来跳去很累分得太粗又失去了模块化的意义。我个人的经验是按照业务领域来划分模块一个模块对应一个相对独立的业务能力比如用户模块、订单模块、支付模块。4. 错误处理与异步流程控制的实战差异错误处理是服务端开发中最容易被低估的部分。很多项目在正常流程下跑得好好的一遇到异常就各种问题。三个框架在错误处理上的差异直接影响了代码的健壮性。4.1 Express 的异步错误陷阱前面提到过Express 4.x 不会自动捕获异步中间件中的错误。这意味着如果你写了这样的代码app.get(/user/:id, async (req, res) { const user await User.findById(req.params.id); if (!user) { throw new Error(User not found); // 这个错误不会被 Express 捕获 } res.json(user); });当用户不存在时throw new Error抛出的错误不会被 Express 的错误处理中间件捕获请求会一直挂起直到超时。这是 Express 项目中最常见的 bug 之一。解决方案有几种。最简单的是在每个 async 函数里手动 try/catchapp.get(/user/:id, async (req, res, next) { try { const user await User.findById(req.params.id); if (!user) { throw new Error(User not found); } res.json(user); } catch (err) { next(err); } });但这样写太啰嗦了。更好的做法是封装一个asyncHandler高阶函数const asyncHandler (fn) (req, res, next) { Promise.resolve(fn(req, res, next)).catch(next); }; app.get(/user/:id, asyncHandler(async (req, res) { const user await User.findById(req.params.id); if (!user) { throw new Error(User not found); } res.json(user); }));这个模式在 Express 社区非常常见基本上每个 Express 项目都会用到。如果你在用 Express 5.x这个问题已经被框架层面解决了但 4.x 的项目还是得自己处理。4.2 Koa2 的错误处理更自然但要注意顺序Koa2 因为原生支持 async/await错误处理写起来自然得多。你只需要在最外层加一个 try/catch 中间件app.use(async (ctx, next) { try { await next(); } catch (err) { ctx.status err.statusCode || err.status || 500; ctx.body { code: ctx.status, message: err.message }; ctx.app.emit(error, err, ctx); } });但这里有一个关键点这个错误处理中间件必须放在所有中间件的最前面。因为 Koa2 的中间件是洋葱模型只有放在最外层才能捕获到所有内层中间件的错误。如果顺序放错了某些中间件的错误就捕获不到。另外Koa2 的ctx.throw()方法很好用可以抛出带有状态码的错误ctx.throw(401, 未授权访问);这个错误会被上面的错误处理中间件捕获然后返回 401 状态码和对应的消息。比手动设置ctx.status和ctx.body要方便。4.3 Nest.js 的异常过滤器体系Nest.js 有一套完整的异常处理机制。框架内置了HttpException类你可以直接抛出throw new NotFoundException(用户不存在);Nest.js 会自动把这个异常转换成对应的 HTTP 响应。除了内置的异常类你还可以自定义异常过滤器来处理特定类型的异常Catch(HttpException) export class HttpExceptionFilter implements ExceptionFilter { catch(exception: HttpException, host: ArgumentsHost) { const ctx host.switchToHttp(); const response ctx.getResponse(); const status exception.getStatus(); response.status(status).json({ code: status, message: exception.message, timestamp: new Date().toISOString() }); } }然后在全局或者控制器级别注册这个过滤器。这套机制的好处是异常处理逻辑可以集中管理不同模块可以有不同的异常处理策略。坏处是概念比较多需要花时间理解。Nest.js 还有一个容易被忽略的点默认情况下未捕获的异常会返回 500 错误但不会记录详细的错误信息。如果你不配置日志出了问题很难排查。所以生产环境中一定要配置好异常过滤器和日志系统。5. 生态与中间件选型的实际考量框架本身只是一部分真正决定开发效率的是围绕框架的生态系统。三个框架在这方面的差异也很大。5.1 Express 的生态最成熟但质量参差不齐Express 因为出现最早生态是最成熟的。基本上你能想到的功能都有对应的中间件。比如passport认证multer文件上传cors跨域处理helmet安全头设置morgan日志但问题是这些中间件的质量参差不齐。有些中间件已经很久没维护了有些中间件的文档写得很差还有些中间件之间有兼容性问题。我在实际项目中就遇到过passport和某个 JWT 中间件冲突的情况排查了大半天才发现是版本不兼容。另外Express 的中间件生态有一个历史遗留问题很多中间件还在用回调风格跟 async/await 混用的时候容易出问题。虽然大部分常用中间件都已经支持 Promise 了但偶尔还是会踩到坑。5.2 Koa2 的生态更精致但选择更少Koa2 的生态比 Express 小但整体质量更高。因为 Koa2 的中间件必须用 async/await 写所以风格比较统一。常用的中间件包括koa-router路由koa-bodyparser请求体解析koa-static静态文件服务koa-session会话管理koa-jwtJWT 认证Koa2 生态的一个特点是很多中间件都是官方出品或者官方推荐的比如koa-router、koa-bodyparser这些维护得都比较好。但 Koa2 的生态也有一个问题选择太少。比如你想找一个功能比较全的权限管理中间件Express 那边有好几个选择Koa2 这边可能就一两个而且不一定完全符合你的需求。这时候就得自己写或者从 Express 的中间件移植过来。5.3 Nest.js 的生态自成体系Nest.js 的生态跟 Express 和 Koa2 不太一样。它不是靠第三方中间件来扩展功能而是框架本身就提供了大部分企业级开发需要的能力。比如nestjs/typeorm数据库 ORM 集成nestjs/graphqlGraphQL 支持nestjs/microservices微服务支持nestjs/swaggerAPI 文档nestjs/config配置管理这些官方包的质量都很高文档也写得好。而且它们之间的集成非常顺畅比如你用nestjs/typeorm定义了实体nestjs/swagger就能自动生成对应的 API 文档。Nest.js 生态的另一个特点是它底层可以跑在 Express 或 Fastify 上。默认是 Express但你可以通过配置切换到 Fastify获得更好的性能。这个设计很聪明既利用了 Express 成熟的生态又给了性能优化的空间。但 Nest.js 的生态也有一个缺点学习成本高。每个官方包都有自己的概念和用法你得花时间一个个学。而且 Nest.js 的版本更新比较快有时候升级版本会遇到 breaking change需要花时间适配。6. 性能表现与适用场景的匹配性能这个话题很容易引起争论因为测试条件不同结果差异很大。我这里不打算给出绝对的结论而是从实际项目经验出发聊聊三个框架在性能上的特点和适用场景。6.1 基准测试的参考价值有限网上有很多三个框架的性能对比测试但说实话这些测试的参考价值有限。因为测试用的业务逻辑通常很简单跟真实项目差距大硬件环境、Node.js 版本、测试工具都会影响结果框架的性能瓶颈往往不在框架本身而在数据库查询、外部 API 调用等我自己的经验是在简单的 CRUD 场景下Express 和 Koa2 的性能差不多Nest.js 大概低 20% 到 30%。但在复杂的业务场景下这个差距会被数据库操作、业务逻辑计算等稀释实际感受不明显。6.2 不同规模项目的选型建议根据我这些年做项目的经验三个框架的适用场景大致可以这样划分项目规模推荐框架理由小型项目、原型验证Express上手快生态全随便怎么写都能跑中型项目、API 服务Koa2结构清晰中间件模型优雅性能好大型项目、企业级应用Nest.js强约束分层清晰适合团队协作需要快速迭代的创业项目Express 或 Koa2灵活改起来快不用被框架约束长期维护的核心系统Nest.js结构稳定新人接手成本低当然这只是一个大致的参考。实际选型还要考虑团队的技术栈、项目的生命周期、性能要求等因素。6.3 我踩过的选型坑说几个我实际踩过的坑希望能帮你避开。第一个坑是用 Express 写大型项目。我接手过一个 Express 项目代码量大概几万行路由文件有几十个中间件嵌套了七八层。每次改一个功能都要花很长时间理清请求链路。后来实在受不了花了两周时间重构成了 Nest.js虽然重构过程很痛苦但之后维护效率明显提升。第二个坑是用 Nest.js 写小项目。有一次做一个内部工具功能很简单就几个接口。我想着用 Nest.js 规范一点结果光是搭项目结构、配置模块就花了大半天。后来想想这种项目用 Express 半小时就能搞定。第三个坑是Koa2 中间件顺序搞错。Koa2 的中间件顺序非常关键我有一次把日志中间件放在了错误处理中间件前面结果错误发生的时候日志中间件已经执行完了错误信息没记录到日志里。排查了半天才发现是顺序问题。7. 从 Express 迁移到 Nest.js 的实操经验如果你正在考虑从 Express 迁移到 Nest.js或者想了解迁移过程中会遇到什么问题这一节的内容应该对你有帮助。我完整经历过一次迁移把一些关键点整理出来。7.1 迁移前的评估不是所有项目都值得迁移迁移框架是一件成本很高的事情不是所有项目都值得做。我建议你先评估几个问题项目是否还在活跃开发如果已经进入维护期迁移的收益不大团队是否愿意学习新框架Nest.js 的学习曲线不低项目是否有结构混乱的问题如果 Express 项目结构本来就清晰迁移的必要性不大是否有足够的测试覆盖没有测试的迁移风险极高我迁移的那个项目是因为结构已经乱到影响开发效率了而且团队里有人用过 Nest.js学习成本可控。如果你的项目没有这些问题建议先优化现有代码而不是急着换框架。7.2 迁移策略渐进式还是重写迁移策略有两种渐进式迁移和完全重写。渐进式迁移是指在现有 Express 项目中逐步引入 Nest.js比如先把某个模块用 Nest.js 重写然后通过某种方式让两个框架共存。这种方式的优点是风险低可以边迁移边验证。缺点是配置复杂两个框架的中间件、错误处理机制需要打通。完全重写是指用 Nest.js 重新实现整个项目。优点是干净彻底没有历史包袱。缺点是风险高周期长而且重写过程中可能会有功能遗漏。我选择的是完全重写因为项目本身不算太大而且渐进式迁移的配置成本太高。重写过程中我先把 Express 的路由和控制器逻辑梳理清楚然后按照 Nest.js 的模块划分重新组织。数据库层基本没动因为用的是 TypeORMNest.js 也有对应的集成包。7.3 迁移中的具体问题与解决迁移过程中遇到了几个具体问题这里列出来供参考。第一个问题是中间件的迁移。Express 的中间件在 Nest.js 里对应的是 Middleware但用法不太一样。Nest.js 的中间件需要实现NestMiddleware接口而且要在模块里注册。一些 Express 的中间件可以直接用比如cors、helmet但有些需要改写。第二个问题是错误处理的迁移。Express 的错误处理中间件在 Nest.js 里对应的是 ExceptionFilter。Nest.js 的异常过滤器功能更强但写法完全不同。我花了一些时间把原来的错误处理逻辑重写成过滤器。第三个问题是依赖注入的引入。Express 项目里通常是手动 require 模块Nest.js 则通过依赖注入来管理。刚开始不太习惯但用久了会发现依赖注入确实让代码更清晰尤其是写单元测试的时候mock 依赖很方便。第四个问题是 TypeScript 的类型定义。Nest.js 默认用 TypeScript所以迁移过程中需要给原来的 JavaScript 代码加上类型定义。这个过程比较繁琐但加完之后代码的可维护性确实提升了。8. 三个框架的长期维护成本对比选框架不能只看开发效率还要看长期维护成本。一个项目上线之后可能要维护好几年维护成本往往比开发成本更高。8.1 代码可读性与新人上手成本从代码可读性来看Nest.js 是最好的。因为它的结构强制分层新人接手的时候只要理解了模块、控制器、服务这几个概念就能快速定位到相关代码。而且 TypeScript 的类型系统本身就是一种文档能帮新人理解数据结构。Express 和 Koa2 的可读性取决于团队的编码规范。如果团队规范执行得好代码也可以很清晰。但如果规范执行不到位代码就会很乱。我见过一个 Express 项目路由、业务逻辑、数据库操作全写在一个文件里一个文件几千行新人根本不敢改。8.2 依赖升级与安全补丁从依赖升级的角度看Express 和 Koa2 的升级相对简单因为它们的核心 API 比较稳定。Express 4.x 已经很多年没大版本更新了Koa2 的 API 也很稳定。Nest.js 的版本更新比较快而且有时候会有 breaking change。比如从 Nest.js 8 升级到 9一些 API 发生了变化需要改代码。但 Nest.js 的升级文档写得很好按照文档一步步来问题不大。安全补丁方面三个框架都有活跃的社区在维护发现安全问题后都会及时修复。但 Nest.js 因为依赖比较多需要关注的依赖也更多。建议使用npm audit或者snyk定期检查依赖的安全性。8.3 社区活跃度与问题解决效率从社区活跃度来看Express 的社区最大遇到问题基本都能搜到答案。但因为 Express 出现得早很多答案可能已经过时了需要注意甄别。Koa2 的社区比 Express 小但核心贡献者比较活跃GitHub 上的 issue 响应速度还可以。Nest.js 的社区虽然相对较小但增长很快而且官方文档非常详细。大部分问题都能在官方文档里找到答案。另外 Nest.js 的 Discord 社区也很活跃遇到问题可以在上面提问。9. 我的选型决策框架聊了这么多最后分享一下我自己的选型决策框架。每次有新项目要定框架我都会按这个框架过一遍。9.1 先问三个问题第一个问题项目预期寿命有多长如果只是做个原型或者临时工具用 Express 快速搞定就行。如果是要长期维护的核心系统Nest.js 更合适。第二个问题团队的技术背景是什么如果团队都是前端转过来的对 TypeScript 和装饰器比较熟悉Nest.js 上手会快一些。如果团队以前主要写 Java 或者 C#Nest.js 的依赖注入和分层架构会让他们感觉很亲切。如果团队都是 JavaScript 老手Express 或 Koa2 可能更顺手。第三个问题项目的性能要求有多高如果 QPS 要求很高Koa2 或者 Express Fastify 可能更合适。如果性能要求一般Nest.js 完全够用。9.2 我的默认选择如果让我给一个默认建议我会说不确定选什么的时候选 Express。它不会让你惊艳但也不会让你踩大坑。生态成熟遇到问题好解决。想要更优雅的代码结构选 Koa2。它的中间件模型确实比 Express 舒服但需要你对 async/await 有比较深的理解。团队协作、长期维护的项目选 Nest.js。前期学习成本高但后期维护成本低。9.3 一个反直觉的建议最后说一个可能有点反直觉的建议不要因为性能而选框架。我见过太多团队为了追求所谓的性能选了某个框架结果项目上线后发现瓶颈根本不在框架而在数据库查询或者外部 API 调用。框架的性能差异在大多数业务场景下是可以忽略的。真正影响性能的是你的数据库设计、缓存策略、代码质量。与其纠结框架的性能不如花时间优化这些方面。当然如果你的项目确实是性能敏感型的比如做实时通信、高频交易之类的那框架的性能就很重要了。但这种场景下你可能需要考虑的更底层的东西比如直接用 Node.js 的http模块或者用更专业的框架。选框架这件事没有标准答案。重要的是理解每个框架的设计哲学和适用场景然后根据你的具体情况做决策。希望这篇内容能帮你理清思路做出适合自己的选择。