答案：设计支持中间件机制的请求库需定义统一中间件接口，采用洋葱模型组织执行链。每个中间件接收上下文和next函数，可修改请求、拦截响应或中断流程。通过use注册中间件，支持全局与局部作用域。上下文共享请求、响应及配置，错误可中断链并被捕获，支持提前返回响应和收尾操作，实现功能扩展与核心逻辑解耦。
设计一个支持中间件机制的请求库，核心是把请求和响应的处理流程拆解成可插拔的阶段，允许开发者在不修改核心逻辑的前提下扩展功能。关键在于定义清晰的执行链和中间件接口。
定义中间件的结构
每个中间件应遵循统一的函数签名，接收上下文对象和下一个中间件的引用。典型的中间件形式如下：
({ request, response, options }, next) => { /* 修改或拦截逻辑 */ }中间件可以：
- 修改请求配置（如添加 header、序列化数据）
- 记录日志或打点监控
- 实现重试、缓存、认证自动刷新
- 拦截并构造假响应（用于测试或降级）
构建执行管道
使用洋葱模型组织中间件，让每个中间件都能控制是否继续向下执行，并能在响应返回时反向执行逻辑。
实现方式：
- 维护一个中间件数组
- 通过递归调用 next() 推动流程进入下一个中间件
- 在 await next() 前处理请求，在之后处理响应
例如：
async function dispatch(ctx, middlewares, index) { if (index >= middlewares.length) return fetch(ctx.request); const middleware = middlewares[index]; return middleware(ctx, () => dispatch(ctx, middlewares, index + 1)); }
暴露中间件注册接口
提供简洁 API 让用户添加中间件：
- use(fn)：按顺序注册中间件
- 支持全局中间件和实例级中间件分离
- 允许指定作用域（如仅特定域名或方法生效）
示例用法：
client.use((ctx, next) => { ctx.request.headers['X-Trace'] = '1'; return next(); });上下文与错误传播
确保每个中间件共享同一个上下文对象，包含请求、响应、配置和自定义字段。错误应在管道中正确抛出和捕获。
- 中间件内部抛错应中断流程并触发 catch
- 支持在任意中间件中直接返回 response 阻止后续执行
- 提供 finally 类似机制处理收尾操作（如 loading 结束）
基本上就这些。只要流程可控、接口清晰，中间件机制就能灵活支撑鉴权、日志、重试等常见需求，同时保持核心请求逻辑轻量。
