一、JavaScript中间件的核心原理与定义
1.1 中间件的定义与职责
在JavaScript的服务器端或前端框架中，中间件是一段可以在请求进入核心处理逻辑前后执行的代码，通过注册、组合与调用形成一条请求处理链。职责划分清晰的中间件可以完成日志输出、身份认证、参数校验、错误处理等职责，而不会将全部逻辑集中在一个函数中，提升代码可维护性。
从执行角度看，中间件像拦截器一样拦截请求，按顺序逐个执行，只有调用了next()才会把控制权交给链上的下一个中间件。如果某个中间件直接发送响应或抛出错误，后续中间件就不会再执行，这样的设计形成了清晰的控制流。控制流的可控性是中间件设计的核心。 next()的调用次数需要受到约束，以避免重复执行。
// 简单的日志中间件示例（Express风格）
function logMiddleware(req, res, next) {console.log(`${req.method} ${req.url}`);next();
}以上示例展示了一个最小化的职责：记录请求信息并把控制权交还给下一个中间件。通过组合多个此类中间件，系统就能获得丰富的处理能力而不需要把逻辑堆积在一个函数内。组合性与单一职责是中间件设计的两大原则。
1.2 执行栈与洋葱模型
在大多数实现中，中间件的执行遵循一个“洋葱模型”或“执行栈”的模式：前置中间件先执行，随后进入核心处理逻辑，最后再由后置中间件回放处理过程，形成前后钩子的组合效果。前序执行通常用于初始化、鉴权校验、参数规范化等，后序执行常用于清理、统计、资源释放等。
为了实现这种流式控制，框架通常提供一个next函数，用于将控制权传递给下一个中间件。若某个中间件返回了响应或者未调用next，后续中间件将不会执行，确保了流程的确定性。下面给出一个简单的“洋葱式”链路组合示例：
function compose(mws) {return function (ctx, next) {let i = -1;function dispatch(n) {if (n <= i) throw new Error('next() called multiple times');i = n;const fn = mws[n];if (!fn) return Promise.resolve(next && next());return Promise.resolve(fn(ctx, () => dispatch(n + 1)));}return dispatch(0);};
};ctx对象在Koa等框架中作为上下文载体，包含请求、响应、状态等信息；在Express等框架中通常使用req、res参数来承载上下文。理解执行栈和next()的工作原理，是设计可维护中间件的关键。
二、常见框架中的中间件实践
2.1 Express 与 Koa 的中间件差异
Express 的中间件通常采用回调风格，next()是控制流的核心，错误处理往往通过具备4个参数的函数来实现：err、req、res、next。这使得错误处理路径相对直观，但也容易因为异步操作而产生回调地狱的问题。
相比之下，Koa 采用了async/await风格，通过ctx上下文对象来传递信息，且中间件以async (ctx, next) => { ...; await next(); ... }的形式实现，洋葱模型在这里表现得更为自然。错误处理可以通过try/catch或外部错误中间件统一处理，代码可读性更高。
// Express 风格中间件
const express = require('express');
const app = express();app.use((req, res, next) => {console.log('Logging');next();
});// Koa 风格中间件
const Koa = require('koa');
const appK = new Koa();appK.use(async (ctx, next) => {ctx.state.started = Date.now();await next();ctx.body = ctx.body || 'OK';
});在实际工程中，很多项目会混合使用两种风格，或者使用一个封装层来统一中间件的签名。关键在于明确执行路径和错误传播的规则，避免跨框架引入不一致的行为。 签名统一与错误传递策略是跨框架实现中间件时必须解决的问题。
2.2 编写可复用的中间件库
可复用中间件具备可配置性、无副作用、可组合性和良好的测试性。通过参数化、职责分离和明确的入口，团队可以把常用功能抽象成公共库，降低项目间的重复工作。下面给出一个可配置的鉴权中间件样例：
function createAuthMiddleware(options) {const { getToken, onForbidden } = options;return function (req, res, next) {const token = getToken(req);if (token && token === 'valid-token') {req.user = { id: 1, name: 'Alice' };return next();}if (onForbidden) return onForbidden(req, res);res.status(401).send('Unauthorized');};
}可配置性（如token获取方式、错误处理）使中间件在不同场景下复用性大幅提升；无副作用确保中间件不会无意间更改全局状态；可测试性通过将外部依赖注入、可预测的输入输出实现。
三、设计模式与最佳实践
3.1 编写可组合的中间件
将功能按职责拆分成独立的中间件，利用组合逻辑把它们拼接成一个管道，是实现大规模应用的关键。推荐的做法是：保持中间件短小、单一职责、可按需开启或关闭。组合性与幂等性是高质量中间件的核心属性。
常见的组合策略包括顺序串联、条件分支、以及“环形调用”模式。下面给出一个简单的组合器示例，演示如何将多个中间件聚合成一个可执行链：
function composeAll(mws) {return function(ctx) {let idx = -1;function dispatch(i) {if (i < 0 || i >= mws.length) return Promise.resolve();if (i > idx) idx = i; const fn = mws[i];if (!fn) return Promise.resolve();return Promise.resolve(fn(ctx, () => dispatch(i + 1)));}return dispatch(0);};
}ctx对象作为上下文载体，包含路径、请求参数、响应信息等；通过ctx的正向传递实现跨中间件的状态共享。
3.2 错误处理的中间件设计
在复杂应用中，错误处理应当统一与可控，避免在各处重复写 try/catch。通常做法是：定义一个全局错误处理中间件，捕获来自前序中间件的异常，统一返回错误码和日志。
设计要点包括：错误签名（统一错误对象结构）、错误传播（确保错误能沿着中间件链向上传播）、以及<幂等性（多次错误处理不会导致重复写入日志或重复响应）。
// 简化的错误处理中间件（异步风格）
async function errorHandler(ctx, next) {try {await next();} catch (err) {ctx.status = err.status || 500;ctx.body = { message: err.message || 'Internal Server Error' };// 统一日志输出console.error('[Error]', err);}
}测试覆盖是保证错误处理正确性的关键，建议对常见异常路径编写单元测试与集成测试。
四、实战案例：自定义日志与鉴权中间件
4.1 日志中间件设计
日志中间件在生产环境中非常常用，目标是尽可能高效、可配置且对请求带来的影响最小。常见设计包括：日志级别、时间戳、请求路径、响应状态码、耗时等信息。日志级别可以从debug到error逐级输出，帮助开发与运维快速定位问题。
下面给出一个基于Express风格的日志中间件样例，支持自定义日志等级与格式：
function createLogger(opts = {}) {const { level = 'info' } = opts;return function (req, res, next) {const start = Date.now();res.on('finish', () => {const duration = Date.now() - start;const msg = `[${new Date().toISOString()}] ${req.method} ${req.originalUrl} ${res.statusCode} ${duration}ms`;// 简化的输出策略，可扩展为真正的日志库if (level === 'debug' || res.statusCode >= 400) {console.log(msg);}});next();};
}通过这种方式，日志信息在请求结束时统一输出，且耗时统计对性能监控极其有用。若将其整合到Koa或其他框架，同样可以保持风格的一致性，只需调整签名即可。
4.2 认证与授权中间件
鉴权中间件用于保护受限的路由，通常从请求头或请求上下文中提取令牌并进行校验。一个简单的实现往往包括：解析令牌、查询令牌有效性、挂载用户信息、如果无效则返回未授权错误。
以下示例展示了一个基于令牌的认证中间件，兼容Express风格的参数签名：
function authMiddleware(tokenStore) {return function (req, res, next) {const token = req.headers['authorization'];if (token && tokenStore.validate(token)) {req.user = tokenStore.decode(token);return next();}res.status(401).send('Unauthorized');};
}tokenStore应提供validate与decode等方法，便于解耦验证逻辑与应用业务。通过将认证逻辑做成可配置的中间件，可以在不同路由或服务中复用，降低重复工作量。
