Koa 常被视为 Express 的“精神续作”，因为它们出自同一开发团队，但 Koa 并不是 Express 的升级版，而是对 Web 框架设计理念的一次彻底重构。理解两者的核心差异，有助于在不同场景下做出正确的技术决策。
1. 中间件执行模型：洋葱模型 vs 线性管道
这是 Express 和 Koa 最本质的区别。
Express 的中间件执行类似一条线性管道：请求依次流过各个中间件，每个中间件可以修改 req 和 res 对象，但当前中间件执行完毕后，控制权就传递给下一个中间件，没有内置机制让控制权再回到上游。尽管可以通过监听 res 的 finish 事件或在回调中实现类似效果，但这并不是 Express 的原生范式。
Koa 则实现了真正的洋葱圈模型：await next() 会将执行权交给下游中间件，当下游所有中间件都执行完成后，控制权会沿着调用栈逐层返回到上游，形成一个“请求 → 中间件1 前半段 → 中间件2 前半段 → ... → 中间件2 后半段 → 中间件1 后半段 → 响应”的完整闭环。
以一个计时中间件为例：
Express 写法：
const express = require('express');
const app = express();
app.use((req, res, next) => {
const start = Date.now();
res.on('finish', () => {
console.log(`${req.method} ${req.url} - ${Date.now() - start}ms`);
});
next();
});Koa 写法：
const Koa = require('koa');
const app = new Koa();
app.use(async (ctx, next) => {
const start = Date.now();
await next();
console.log(`${ctx.method} ${ctx.url} - ${Date.now() - start}ms`);
});Koa 的写法更直观：在 await next() 之前的代码是请求进入阶段，之后的代码是响应离开阶段。这种模型使得日志记录、性能监控、响应包装等需要“环绕”下游中间件的逻辑变得非常自然。
2. 异步处理：async/await 原生支持 vs callback 约定
Express 诞生于 2010 年，当时 JavaScript 的异步主流还是回调函数，Promise 尚未普及。因此 Express 的中间件函数签名是 (req, res, next)，错误处理需要通过 next(err) 显式传递。如果在 Express 的中间件中抛出异步错误（比如一个被拒绝的 Promise 未捕获），Express 无法自动捕捉，会导致请求挂起或进程崩溃。虽然 Express 4 开始可以通过包裹一层 try/catch 并手动调用 next(err) 来部分解决，但写法繁琐，且容易遗漏。
Koa 从设计之初就建立在 Promise 之上，所有中间件都是 async 函数（或返回 Promise 的函数）。你可以直接在中间件中使用 try/catch 捕获异步错误，然后通过 ctx.throw() 或设置 ctx.status 和 ctx.body 来统一处理。这使得错误处理逻辑与业务代码保持在同一层级，不再需要单独的 (err, req, res, next) 中间件来捕获异常。
Express 中处理异步错误：
app.get('/user', async (req, res, next) => {
try {
const user = await fetchUser();
res.json(user);
} catch (err) {
next(err);
}
});
// 错误处理中间件
app.use((err, req, res, next) => {
res.status(500).json({ error: err.message });
});Koa 中处理异步错误：
app.use(async (ctx, next) => {
try {
await next();
} catch (err) {
ctx.status = 500;
ctx.body = { error: err.message };
}
});
router.get('/user', async (ctx) => {
const user = await fetchUser();
ctx.body = user;
});Koa 的方案显著减少了模板代码，且不易遗漏错误处理。
3. 上下文封装：ctx vs req/res
Express 通过扩展 Node.js 原生的 http.IncomingMessage 和 http.ServerResponse 对象（即 req 和 res）来提供 Web 开发能力。这让你直接在原始的请求响应对象上操作，例如 req.body、res.status(200).json(data)。
Koa 则将 req 和 res 封装进一个统一的 ctx 对象（Context）。ctx.request 是 Koa 的请求对象，ctx.response 是 Koa 的响应对象，而 ctx.req 和 ctx.res 保留了原始的 Node.js 对象。这种封装的优点是：
- 更简洁的 API 命名：
ctx.status = 200、ctx.body = data、ctx.query等。 - 便于在中间件之间传递数据（通过
ctx.state）。 - 提供了很多便捷属性，如
ctx.request.ip、ctx.request.hostname等，无需手动从req.headers中解析。
但也因为这种封装，Koa 默认不提供 req.body 解析、路由、静态文件服务等功能，需要用户手动添加中间件。Express 则内建了一些便利能力（如 express.json()、express.static() 等）。
4. 功能完整度：极简核心 vs 自带电池
Express 发布时就自带了路由功能（express.Router()）、静态文件中间件、视图渲染引擎集成等。而 Koa 的核心极其精简，只提供中间件引擎和上下文封装。路由、请求解析、静态文件、模板渲染等全部需要引入第三方中间件（如 @koa/router、koa-body、koa-static、koa-views）。
这并非缺陷，而是设计哲学不同：
- Express 追求开箱即用，适合快速搭建项目，新手友好。
- Koa 追求极致可控，不愿意在核心中加入任何“可能不是所有人都需要”的功能，鼓励开发者根据需求组合中间件，保持应用的轻量级。
这也意味着 Koa 项目的起步需要更多的初始配置，但进入中后期后，因为一切都是显式组合的，依赖关系更清晰，定制更灵活。
5. 性能与社区生态
在纯框架层面，Koa 比 Express 略微轻量，但性能差距通常不是选择的主要理由。两个框架的性能瓶颈几乎都取决于业务逻辑和 I/O 操作，而不是框架本身的中间件调度开销。不过在极端并发场景下，Koa 的 Promise 化中间件调度和更少的内部封装可能带来微小的吞吐量优势。
社区生态方面：
- Express 拥有目前最大的中间件生态，几乎所有可想到的功能都有现成的 Express 中间件可供使用。大量的教程、书籍、课程都以 Express 为基础，开发者遇到问题时能快速找到解决方案。
- Koa 的生态相对较小，但由于 Koa 2.x 的推广和 Node.js 社区的成熟，主流功能（路由、鉴权、日志、校验）都有对应的稳定包。并且很多新框架（如 Egg.js）直接基于 Koa 构建，说明其设计得到了认可。
6. 选型建议：什么时候该用哪个？
优先选择 Express 的场景：
- 项目需要快速启动，希望框架本身提供大量内置功能（路由、静态文件、请求体解析），减少初期配置。
- 团队成员大多是 Node.js 新手，或已经非常熟悉 Express 的范式，学习成本更低。
- 项目需要依赖大量第三方 Express 中间件，切换框架可能导致找不到对应 Koa 替代品。
- 项目周期短，或对框架的极致灵活性没有太高要求，Express 的约定已经足够。
优先选择 Koa 的场景：
- 团队对 async/await 和 Promise 的掌握程度较高，愿意拥抱现代化的异步处理方式，并接受“组合而非继承”的哲学。
- 需要更优雅的洋葱圈模型来统一实现日志、鉴权、响应包装、性能监控等横切关注点，而不依赖各种 hack。
- 项目规模中等偏大，团队希望完全掌控中间件的组合顺序和依赖，避免 Express 隐式行为带来的意外。
- 系统对性能有较高要求（如高频 API 网关），并且愿意为了一点吞吐量优势而接受稍多的初始配置。
- 打算使用基于 Koa 的上层框架（如 Egg.js），直接掌握 Koa 核心会加深理解。
真实世界中的混合思路：
很多团队最终并不会在 Express 和 Koa 之间做“二选一”的硬性切割。比如：
- 新建项目时用 Koa 体验更现代的异步开发模型。
- 维护老项目时继续用 Express，因为替换成本太高且运行良好。
- 如果希望同时拥有 Express 的生态和 Koa 的中间件模型，可以考虑像
@eggjs/koa或直接使用 NestJS 这样同时兼容 Express 底层适配器的上层框架。
总之，Express 和 Koa 不是对立关系，而是同一技术理念在不同时期的表达。理解它们的核心差异，你就能根据团队能力、项目周期、功能需求做出最务实的选择。