在 12.1 节介绍 Express 时，我们看到它的中间件机制是线性的“管道”模型：请求依次经过每个中间件，每个中间件可以决定将请求传递给下一个，或者终止响应。Koa 则在此基础上发展出了一种更优雅、更强大的中间件组合方式——洋葱模型，并且依靠原生的 async/await 将异步流程控制完全交由语言本身。这二者结合，极大降低了复杂异步中间件的编写难度，也让代码更像按顺序执行的同步逻辑。
洋葱模型：请求经过层层包裹，再原路返回
Koa 的中间件是一个 async 函数，接受两个参数：ctx（上下文）和 next（下一个中间件的调用函数）。当你在中间件里调用 await next() 时，控制权会交给下一个中间件，所有中间件的执行路线就像一个洋葱的切面：从外向内进入，再从内向外返回。
想象一个现实中的场景：某个请求需要被记录日志、进行权限校验、处理业务逻辑，最后返回 JSON。Koa 的洋葱模型允许你在 await next() 之前做一些事，之后再回来做一些事，非常适合处理“请求前”和“请求后”的对称逻辑。
下面的代码能直观说明问题：
const Koa = require('koa');
const app = new Koa();
// 第一个中间件：记录请求耗时
app.use(async (ctx, next) => {
const start = Date.now();
console.log('1. 请求到达，开始计时');
await next(); // 进入下一个中间件
const ms = Date.now() - start;
console.log(`5. 请求结束，耗时 ${ms}ms`);
ctx.set('X-Response-Time', `${ms}ms`);
});
// 第二个中间件：假装的权限校验
app.use(async (ctx, next) => {
console.log('2. 开始校验权限');
await next(); // 进入下一个中间件
console.log('4. 权限校验结束（后续操作，例如清理）');
});
// 第三个中间件：实际业务处理
app.use(async (ctx) => {
console.log('3. 业务逻辑处理中');
ctx.body = { message: 'Hello Koa' };
});
app.listen(3000);当客户端发起请求时，控制台输出为：
1. 请求到达，开始计时
2. 开始校验权限
3. 业务逻辑处理中
4. 权限校验结束（后续操作，例如清理）
5. 请求结束，耗时 3ms可以看出，执行路径是 1 → 2 → 3 → 4 → 5。await next() 就像一扇扇门：进去时挨个打开，出来时再挨个关上。这就是洋葱模型名称的由来。每个中间件都有能力在“前置”和“后置”阶段做事情，非常适合记录日志、计算耗时、处理异常、发送通知等场景。
async/await 原生支持：异步不再需要特殊处理
Koa 洋葱模型能够顺畅工作的基石，是所有中间件都被当作返回 Promise 的 async 函数处理。在 Express 中，如果你在中间件里做一个异步操作（例如读取数据库），然后想在操作结束后执行另一个操作，通常需要手动调用 next()，或者将其放在一个 promise 的回调中。代码很容易变成多层嵌套，可读性下降。
Koa 彻底摆脱了这些约束。当你使用 await 等待一个异步操作时，中间件的执行流会暂停在当前位置，等操作完成后继续往下，整个过程就像写同步代码一样自然。如果中间件内部没有调用 await next()，Koa 也会正常等待整个 async 函数完成，然后沿洋葱路径返回。
一个更具实际价值的例子：从数据库查询用户信息，并设置响应：
app.use(async (ctx, next) => {
// 前置操作：可以在这里做一些初始化
const user = await db.query('SELECT * FROM users WHERE id = ?', [ctx.params.id]);
if (!user) {
ctx.status = 404;
ctx.body = { error: '用户不存在' };
return; // 直接返回，不再进入后续中间件
}
ctx.state.user = user; // 将数据挂到上下文，后续中间件可用
await next(); // 进入业务处理层
// 后置操作：业务层执行完毕，可以记录操作日志
logger.info(`用户 ${user.id} 已访问`);
});这个例子中，数据库查询是异步的，但我们用 await 让它看起来是同步等待结果。如果用户不存在，直接返回 404 并终止请求。如果存在，则将用户数据放入 ctx.state，供后面的中间件使用。最后，在 await next() 返回之后，再写入一条日志。整个流程没有任何回调嵌套，错误也可以通过 try...catch 统一捕获。
洋葱模型下的错误处理
由于洋葱模型的中心是对称的进出过程，错误处理也变得极其简洁。你可以在最外层中间件里用一个 try...catch 包裹 await next()，这样内部任何中间件抛出的异常（无论是同步错误还是被 await 的 Promise 拒绝）都会被捕获，从而做统一处理。
app.use(async (ctx, next) => {
try {
await next();
} catch (err) {
ctx.status = err.status || 500;
ctx.body = { error: err.message };
// 可选：上报到错误监控系统
logError(err);
}
});
app.use(async (ctx) => {
// 模拟业务出错
throw new Error('业务崩溃');
});上面的代码会在最外层捕获到 业务崩溃 这个错误，并返回 500 给客户端。在 Express 中，要实现类似的效果需要专门定义一个错误处理中间件（签名包含 (err, req, res, next)），而 Koa 直接利用语言层面的 try/catch，更符合直觉。
与 Express 的对比
| 特性 | Express | Koa |
|------|---------|-----|
| 中间件模型 | 线性管道，next() 只能向下游传递 | 洋葱模型，可下游进入后返回上游执行后置逻辑 |
| 异步处理 | 回调风格，遇到异步需手动调用 next(err) 或回 Promise | 原生支持 async/await，直接 await next() 即可 |
| 错误捕获 | 单独的错误处理中间件 | try...catch 包裹 await next() |
| 上下文对象 | 分开的 req, res | 合并的 ctx，包含 request、response、state 等 |
| 设计哲学 | 依赖中间件生态，功能通过中间件扩展 | 更精简的核心，洋葱模型提供了强大的组合能力 |
需要注意的是，Koa 本身比 Express 更“薄”：它没有内置路由、静态资源服务或视图引擎，一切都通过额外的中间件（如 koa-router、koa-static）来实现。这给了开发者更大的自由度，但也要求对中间件原理有更好的理解。
洋葱模型开发中的注意事项
在日常使用 Koa 的过程中，几个常见的问题值得留意：
- 别忘了
await next()
如果在中间件里忘记写 await next()，后续的中间件将永远不被执行。虽然 next() 返回的是一个 Promise，但不 await 就相当于放弃等待，洋葱链条会断裂，且 Koa 不会报错，可能导致难以排查的逻辑错误。
- 避免在
await next()之后抛出普通错误
洋葱的外层中间件可以正常 try/catch 内部错误，但如果外层在 await next() 之后抛出未捕获的异步错误（例如一个未被 await 的 Promise 异常），这个错误可能无法被外层捕获，最终变成未处理的 Promise 拒绝而导致进程崩溃。保持一致的 async/await 风格，就能避免这类问题。
- 利用
ctx.state作为中间件间的通信渠道
和 Express 使用 req 对象挂载自定义属性类似，Koa 的 ctx.state 是推荐的信息传递媒介。例如，在认证中间件中将解析出的用户信息放到 ctx.state.user，业务中间件就能直接获取，无需污染原生的请求/响应对象。
- 洋葱模型与响应体设置
只有最内层的中间件（通常不调用 next() 的那个）通常负责设置 ctx.body。但如果内层只是修改了状态码，外层也可以在 await next() 之后再补充或修改响应体。这在需要做统一格式包装（比如将业务结果包进 { code: 0, data: ... }）时非常有用。
小结
Koa 的洋葱模型将中间件从单纯的“管道”升级为“对称的皮皮虾皮”，而 async/await 原生支持让编写异步中间件如同编写同步代码，极大降低了复杂逻辑的心智负担。正是这两个设计起家的特点，让 Koa 在需要优雅地处理请求前/后操作、统一错误过滤、以及构建大型分层服务的场景下，比传统框架更具表达力和可维护性。虽然 Koa 本身很精简，但它的中间件组合能力成为许多上层框架（如 Egg、ThinkJS）的基础，也直接启发了 Express 5 对 Promise 支持的改进。