Express 5 与 4 并存：Node.js 最老牌框架的现状与迁移判断

一个解决“不想被框架管”的问题

Express 解决的问题很具体：在 Node.js 里写 HTTP 服务时，你不想被迫使用某个 ORM、模板引擎或项目结构。它的定位是“不固执己见”，只提供路由、中间件和少量 HTTP 工具，其余全部交给你。这个定位决定了它的目标用户：想自己拼装技术栈的工程师，以及需要快速交付 API 或页面的团队。它不适合想要“全家桶”的人，比如希望框架内置数据库迁移、权限校验或依赖注入容器。Express 的克制既是优点也是边界，你得到的是自由，代价是很多决定必须自己做。

中间件与路由：机制比看起来简单

Express 的核心机制是中间件链。每个请求按注册顺序流过一组函数，每个函数可以结束响应，也可以调用 `next()` 交给下一个。路由是这条链的特例，`app.get('/'， handler)` 本质上是在路径匹配时执行的中间件。文档给出了最小示例，`app.get('/', (req, res) => { res.send('Hello World') })`，这个模式可以扩展到任意复杂度的应用。路由支持参数、通配符和正则，但 v4 与 v5 的路径语法有差异，v5 使用了 `path-to-regexp` 的更新版本，某些旧写法会失效。中间件可以来自 `express.json()` 这类内置工具，也可以来自 npm 上的第三方包，官方维护的中间件集中在 `expressjs` 组织下。理解这条链，就理解了 Express 的大部分行为。

模板引擎：14 种，但都是可选的

Express 的模板支持通过 `@ladjs/consolidate` 实现，官方声称支持超过 14 种模板引擎。这意味着你可以用 Pug、EJS、Handlebars 或任何 consolidate 支持的引擎，也可以完全不用模板，直接返回 JSON。这种设计延续了“不强迫”的理念，视图系统只是一个可插拔的层。实际使用中，你需要在 `app.set('view engine', 'pug')` 这类配置后，通过 `res.render()` 渲染页面。但注意，模板引擎的选择会影响渲染性能与调试体验，Express 本身不提供任何默认模板，所有配置都要自己写。对于纯 API 项目，这个功能完全用不上，它只是给服务端渲染留了一条路。

安装与生成器：三分钟跑起来

安装很简单，`npm install express` 即可，但要求 Node.js 18 或更高版本。官方推荐用生成器快速创建项目：先安装 `express-generator@4`，注意生成器的版本与 Express 主版本对应，然后运行 `express /tmp/foo` 创建应用，接着 `npm install` 和 `npm start`，访问 `http://localhost:3000` 就能看到页面。生成器会搭好目录结构、入口文件和基础路由，这对新手很友好。但生成器生成的代码是 v4 风格，如果你打算用 v5，需要手动调整，或者等待生成器更新。README 里特意提示要阅读 v5 迁移指南，说明 v4 到 v5 的差异不是小修小补。

v5 与 v4：两个版本并行的现实

仓库的 recent releases 显示，v5.2.1 在 2025 年 12 月发布，而 v4.22.2 在 2026 年 5 月仍在更新，这意味着 v4 还在维护。v5 是主推版本，但 v4 依然被广泛使用，尤其是老项目。v5 的迁移指南被官方单独强调，主要变化包括：移除了一些废弃 API、`req.query` 改为只读的 getter、中间件错误处理行为调整、路由通配符语法变化。这些改动会破坏现有代码，所以升级不是无痛的。对于新项目，直接使用 v5 是合理选择，但如果你依赖某些只兼容 v4 的第三方中间件，需要先确认其兼容性。两个版本并行维护，说明 Express 团队在平衡稳定性与演进，这也意味着短期内 v4 不会被抛弃。

局限与误用场景

Express 的局限在文档里没有明说，但从设计能看出来。第一，它没有内置的异步错误处理，如果中间件里的 Promise reject，需要自己捕获并传给 `next(err)`，否则请求会挂起。第二，它不提供 TypeScript 类型定义，需要安装 `@types/express`，而且类型定义可能滞后于版本更新。第三，路由和中间件是线性链，对于复杂应用，组织代码需要额外模式，比如分层或依赖注入，这些 Express 都不管。第四，性能不是它的强项，README 说“关注高性能”，但对比 Fastify 或 Hono 这类现代框架，Express 的基准测试通常不占优。如果你的应用需要极高的并发吞吐，或者团队希望框架提供更多约束，Express 可能是错误工具。

替代方案：Fastify 与 Hono 的差异

最常见的替代是 Fastify。Fastify 同样走中间件路线，但内置了 schema 校验、日志和性能优化，TypeScript 支持也更好。它用 JSON schema 定义路由参数与响应，能自动生成文档，而 Express 需要自己写校验逻辑。另一个替代是 Hono，它设计为跨运行时，支持 Node.js、Deno 和 Cloudflare Workers，使用 Web 标准 API，体积小，适合边缘计算场景。Express 与它们的核心差异在于：Express 保持最小，Fastify 提供更多内置能力，Hono 追求运行时无关。选择取决于你的部署目标，如果只跑在 Node.js 且不想学新概念，Express 仍然够用；如果追求性能或边缘部署，Hono 更合适。

维护成本与许可证

Express 采用 MIT 许可证，可以自由使用和修改，没有商用限制。维护方面，项目有技术委员会和 triagers 的治理结构，README 列出了完整的成员名单，说明它不是一个个人项目。但从更新节奏看，v4 的修复频率较低，v5 是主要开发分支。升级成本是真实的，v4 到 v5 需要改代码，而且生成器版本要匹配，文档也提醒先读迁移指南。测试方面，仓库自带测试套件，运行 `npm install` 后执行 `npm test` 即可，但那是贡献者的事，普通用户不需要。长期看，Express 的维护是可持续的，但它的演进速度较慢，新特性不会频繁出现，这是稳定框架的常态。

编辑结论

Express 适合需要快速搭建 HTTP API 或服务端渲染页面的中小型项目，尤其是团队已熟悉回调与中间件模式、不愿被框架约束的场景。不适合追求内置 TypeScript 支持、需要复杂依赖注入或希望框架自带异步错误边界的项目，这类需求应转向 Fastify、NestJS 或 Hono。采用前应确认 Node.js 版本不低于 18，并仔细阅读官方 v5 迁移指南，因为 v4 与 v5 的中间件签名、路由语法和 `req.query` 行为都有变化。若项目已稳定运行在 v4 且无升级压力，不必急于迁移，但新项目应直接选 v5，避免重复迁移成本。最终判断：Express 的价值不在新特性，而在其稳定与普及，选它意味着接受它的克制，也接受它把更多决策留给你。

官方来源

1. Official documentation
2. Official README
3. Project repository
4. Release notes