洋葱模型
洋葱模型（Onion Model）是中间件执行的核心逻辑模式，特点是请求先逐层穿过外层中间件到达核心逻辑，再反向逐层穿过外层中间件返回，形似洋葱的层级结构。每个中间件既可以处理 “进入” 阶段的逻辑（如前置校验），也可以处理 “返回” 阶段的逻辑（如结果处理）。
假设存在两个中间件 A 和 B，以及核心逻辑 C，执行顺序如下：进入 A → 进入 B → 执行 C → 离开 B → 离开 A 整个流程像剥洋葱一样，从外层到内层，再从内层回到外层。
代码实现洋葱模型
executeOnion 函数使用递归和闭包实现了中间件的 “逐层进入、逐层返回” 逻辑，核心是 next() 函数的闭包特性—— 它能记住当前执行到的中间件索引（index），每次调用 next() 就 “推进” 到下一个中间件，直到所有中间件执行完毕后触发核心逻辑。
-
executeOnion 函数是洋葱模型的核心，它接受三个参数：middlewares 中间件数组，core 核心逻辑，ctx 全局上下文对象，然后就是记录index和执行next函数
-
index 是 executeOnion 函数作用域内的变量，next() 作为闭包能持续访问和修改它 —— 每次调用 next()，index 就会递增，确保中间件按顺序执行
-
next 函数是每次调用都“消费”一个中间件，每次调用 next()，index 就会递增，确保中间件按顺序执行，当 index 达到中间件长度时，执行核心逻辑， 核心逻辑 core 是最后一个中间件，当所有中间件执行完后，执行核心逻辑
- 每个中间件是一个函数，常用参数是
ctx 和 next，ctx 是用于在中间件之间、中间件与核心逻辑之间传递数据（如请求参数、状态、结果），避免使用全局变量，保证数据隔离；next 用于触发下一个中间件或核心逻辑，是实现 “逐层进入、逐层返回” 的关键。中间件参数本质是解决数据共享和流程串联。
-
await next() 的核心作用是启动整个洋葱流程，index 的递增是由 next() 函数内部的逻辑完成的。await next()是 “触发按钮”，而 index 递增是 “按钮按下后内部的机械动作”—— 按钮本身不直接推动 index，但按下按钮会触发推动 index 的逻辑。
// 洋葱模型执行器：递归串联中间件和核心逻辑
const executeOnion = async (middlewares, core, ctx) => {
let index = 0; // 记录当前执行到的中间件下标（闭包变量），
// 定义next函数：每次调用都“消费”一个中间件，next函数是一个async函数，所以可以await下一个中间件或核心逻辑
const next = async () => {
if (index < middlewares.length) {
// 1. 取出当前下标对应的中间件
const currentMiddleware = middlewares[index];
// 2. 下标+1，为下一次调用next()做准备
index++;
// 3. 执行当前中间件，并把ctx和next传给它
await currentMiddleware(ctx, next);
} else {
// 4. 所有中间件执行完后，执行核心逻辑
await core(ctx);
}
};
// 启动：第一次调用next()，开始执行第一个中间件
await next();
};
// 定义中间件数组
const middlewares = [
// 中间件1：日志记录
async (ctx, next) => {
console.log('中间件1 - 进入');
await next(); // 执行下一个中间件/核心逻辑
console.log('中间件1 - 离开');
},
// 中间件2：耗时统计
async (ctx, next) => {
const start = Date.now();
console.log('中间件2 - 进入');
await next(); // 执行下一个中间件/核心逻辑
const end = Date.now();
console.log(`中间件2 - 离开，耗时：${end - start}ms`);
},
];
// 核心逻辑
const coreLogic = async (ctx) => {
console.log('执行核心逻辑');
ctx.result = '核心逻辑结果';
};
// 测试执行
const ctx = {};
executeOnion(middlewares, coreLogic, ctx).then(() => {
console.log('最终结果：', ctx.result);
});
// 输出：
// 中间件1 - 进入
// 中间件2 - 进入
// 执行核心逻辑
// 中间件2 - 离开，耗时：xms
// 中间件1 - 离开
// 最终结果：核心逻辑结果
详细的执行过程
// 初始状态：index = 0
await next(); // 第一次调用 next()
// next() 内部执行：
// 1. index=0 < 2 → 取出中间件1
// 2. index++ → index=1
// 3. 执行中间件1：console.log('中间件1进') → 调用 await next()（第二次调用 next()）
// 第二次调用 next() 内部：
// 1. index=1 < 2 → 取出中间件2
// 2. index++ → index=2
// 3. 执行中间件2：console.log('中间件2进') → 调用 await next()（第三次调用 next()）
// 第三次调用 next() 内部：
// 1. index=2 ≥ 2 → 执行核心逻辑
// 2. 核心逻辑执行完，回到中间件2的 await next() 之后 → console.log('中间件2出')
// 3. 中间件2执行完，回到中间件1的 await next() 之后 → console.log('中间件1出')
// 4. 中间件1执行完，回到第一次 await next() 之后 → 整个流程结束
深度理解中间件的代码，把中间件 1 的代码拆成三步看：
async (ctx, next) => {
// 第一步：进入中间件1，先执行“进入”逻辑
console.log('中间件1 - 进入');
// 第二步：调用next()，触发后续所有逻辑（中间件2 → 核心逻辑）
// 这里的await会“暂停”中间件1的执行，直到next()对应的Promise完成
await next();
// 第三步：只有等next()的所有后续逻辑执行完，才会走到这里
console.log('中间件1 - 离开');
};
关键：await next() 的 “暂停 - 恢复” 机制
- 暂停：当执行到
await next() 时，中间件 1 的执行会暂停，JavaScript 引擎会去执行 next() 指向的逻辑（中间件 2）；
- 递归触发：中间件 2 里也有
await next()，会继续暂停中间件 2，触发核心逻辑；
- 恢复：核心逻辑执行完后，中间件 2 的
await next() 完成，继续执行中间件 2 的后续代码（“中间件 2 - 离开”）；中间件 2 执行完后，中间件 1 的 await next() 才完成，继续执行中间件 1 的后续代码（“中间件 1 - 离开”）。
把中间件的执行逻辑用嵌套函数模拟，会更直观：
// 模拟中间件1的执行
const middleware1 = async () => {
console.log('中间件1 - 进入');
// 模拟await next()：执行中间件2
await middleware2();
console.log('中间件1 - 离开');
};
// 模拟中间件2的执行
const middleware2 = async () => {
console.log('中间件2 - 进入');
// 模拟await next()：执行核心逻辑
await coreLogic();
console.log('中间件2 - 离开');
};
// 模拟核心逻辑
const coreLogic = async () => {
console.log('执行核心逻辑');
};
// 启动执行
middleware1();
await next() 就像 “打开一扇门进入内层”，只有等内层的所有事情（后续中间件、核心逻辑）全部办完，门才会关上，回到当前中间件继续执行后续代码。这也是为什么中间件的 “离开” 逻辑会按反向顺序执行 —— 内层逻辑必须先完成，外层才能收尾。
考验环节
- 请用一句话概括「洋葱模型」的核心执行逻辑，并用通俗的例子解释它的应用场景？
- 洋葱模型中，next() 函数的核心作用是什么？如果某个中间件里不调用 next()，会发生什么？
已知以下中间件数组和核心逻辑，结合我们之前写的 executeOnion 执行器：
const middlewares = [
async (ctx, next) => {
console.log('A 进');
ctx.msg = 'A';
await next();
console.log('A 出');
},
async (ctx, next) => {
console.log('B 进');
ctx.msg += 'B';
await new Promise((resolve) => setTimeout(resolve, 1000)); // 模拟异步
await next();
console.log('B 出');
},
async (ctx, next) => {
console.log('C 进');
ctx.msg += 'C';
await next();
console.log('C 出');
},
];
const coreLogic = async (ctx) => {
console.log('核心逻辑');
ctx.msg += '核心';
};
-
请写出最终的控制台输出顺序（包括耗时相关日志）？
-
执行完后，ctx.msg 的值是什么？
-
如果把中间件 B 的 await next() 改成 next()（去掉 await），输出顺序会发生什么变化？为什么？
-
请基于洋葱模型，实现一个简化版的「Zustand 日志中间件」—— 要求：
- 拦截 store 的 set 操作，打印「更新前状态」和「更新后状态」；
- 支持异步 set 操作（比如异步修改状态）；
- 无需依赖 Zustand 源码，用伪代码模拟核心逻辑即可。
// 模拟Zustand的create函数（带中间件支持）
const create = (initializer) => {
let state;
// 中间件包装后的set方法
const setState = (updater) => {
// 处理函数式更新（如 (s) => ({ count: s.count + 1 })）
const newState = typeof updater === 'function' ? updater(state) : updater;
state = { ...state, ...newState }; // 合并新状态
};
// 初始化store（执行用户传入的initializer）
state = initializer(setState, () => state);
return {
getState: () => ({ ...state }), // 返回状态副本，避免外部修改
setState,
};
};
// 使用中间件创建store
const initializer = (set, get) => ({
count: 0,
// 同步方法
increment: () => set((s) => ({ count: s.count + 1 })),
// 异步方法
asyncIncrement: async () => {
await new Promise((resolve) => setTimeout(resolve, 1000));
set((s) => ({ count: s.count + 1 }));
},
});
const useCounterStore = create(initializer);
// 实现日志中间件（洋葱模型思路） 调用 setState 前，打印「更新前状态：xxx」，调用 setState 后，打印「更新后状态：xxx」；
// const logMiddleware = 实现
// const useCounterStore = create(logMiddleware(initializer));
// 测试
console.log('初始状态：', useCounterStore.getState()); // 初始状态：{ count: 0 }
useCounterStore.increment(); // 触发同步更新
useCounterStore.asyncIncrement(); // 触发异步更新
- 除了 Zustand/Koa，你还知道哪些前端框架 / 库用到了洋葱模型？它在这些场景中解决了什么问题？
- 洋葱模型和「责任链模式」有什么区别？请举例说明（比如两者在处理请求时的不同逻辑）。
- 假设你正在开发一个接口请求工具，需要通过中间件实现「请求拦截（加 Token）」「响应拦截（统一处理错误）」「日志记录（打印请求耗时）」，请用洋葱模型设计这三个中间件的执行顺序，并简要说明理由。
下面是使用的逻辑，请开发 createRequestEnhancer
// 创建实例
const request = createRequestEnhancer();
// 添加日志中间件（前置+后置逻辑）
request.use(async (ctx, next) => {
console.log('日志：请求开始，URL=', ctx.url);
const start = Date.now();
await next(); // 执行后续中间件+核心请求
console.log('日志：请求结束，耗时=', Date.now() - start, 'ms');
});
// 添加请求拦截中间件（前置逻辑）
request.use(async (ctx, next) => {
console.log('请求拦截：添加Token');
ctx.options.headers = {
...ctx.options.headers,
Authorization: 'Bearer 123456',
};
await next();
});
// 添加响应拦截中间件（后置逻辑）
request.use(async (ctx, next) => {
await next(); // 先执行核心请求
console.log('响应拦截：格式化数据');
ctx.response = { code: 200, data: ctx.response }; // 包装响应
});
// 发送请求（测试洋葱模型）
request
.fetch('https://jsonplaceholder.typicode.com/todos/1')
.then((res) => console.log('最终结果：', res))
.catch((err) => console.log('错误：', err));
// 执行的时候
// 日志：请求开始，URL= https://jsonplaceholder.typicode.com/todos/1
// 请求拦截：添加Token
// （核心fetch请求）
// 响应拦截：格式化数据
// 日志：请求结束，耗时= 120 ms
// 最终结果： { code: 200, data: { userId: 1, id: 1, title: '...', completed: false } }
- 如果中间件数组很长（比如 100 个），洋葱模型的递归实现会导致栈溢出吗？如果会，如何优化执行器的实现（非递归方式）？
答案
- 请用一句话概括「洋葱模型」的核心执行逻辑，并用通俗的例子解释它的应用场景？
参考：洋葱模型的关键是 “逐层进入、逐层返回” 的双向流程，请求先逐层穿过外层中间件到达核心逻辑，再反向逐层穿过外层中间件返回（“进 - 核心 - 出” 的双向流程）。通俗例子：比如 Koa 处理 HTTP 请求时，先通过日志中间件记录请求开始（进），再通过权限中间件校验身份（进），执行核心的接口处理逻辑后，再通过权限中间件记录校验结果（出），最后通过日志中间件记录请求结束（出），全程不修改核心接口逻辑。
- 洋葱模型中，next() 函数的核心作用是什么？如果某个中间件里不调用 next()，会发生什么？
- next() 的核心作用：触发下一个中间件或核心逻辑的执行，是串联洋葱模型 “逐层进入” 的关键，同时保证执行完后续逻辑后能回到当前中间件的 await next() 之后（实现 “逐层返回”）。
- 若某个中间件不调用 next()：后续所有中间件和核心逻辑都会被阻断（相当于 “拦截”），当前中间件 next() 之后的代码也不会执行（因为没有后续逻辑触发返回）。
-
请写出最终的控制台输出顺序（包括耗时相关日志）？
A 进 -> B 进 -> （等待 1s） -> C 进 -> 核心逻辑 -> C 出 -> B 出 -> A 出
-
执行完后，ctx.msg 的值是什么？
ABC 核心
-
如果把中间件 B 的 await next() 改成 next()（去掉 await），输出顺序会发生什么变化？为什么？
中间件 B 的代码里有 await new Promise(resolve => setTimeout(resolve, 1000))（1s 异步延迟），如果把 await next() 改成 next()，执行顺序会变成：A 进 -> B 进 （触发 next()但不等待，直接执行 console.log('B 出')）-> B 出 -> A 出（1s 后） -> C 进 -> 核心逻辑 -> C 出。因为 next 是 async 函数，所以会返回一个 Promise，进入了微任务队列。
// 中间件B的代码
async (ctx, next) => {
console.log('B 进');
await new Promise((resolve) => setTimeout(resolve, 1000)); // 等待1s（宏任务完成）
// 调用 next()，但不 await
next(); // next()是 async 函数，返回 Promise，进入微任务队列
console.log('B 出'); // 主线程代码，直接执行
};
// 中间件 C 的代码（同步）
async (ctx, next) => {
console.log('C 进'); // 微任务：需等主线程执行完才会触发
await next(); // 同步执行核心逻辑
console.log('C 出');
};
-
请基于洋葱模型，实现一个简化版的「Zustand 日志中间件」—— 要求：
- 拦截 store 的 set 操作，打印「更新前状态」和「更新后状态」；
- 支持异步 set 操作（比如异步修改状态）；
- 无需依赖 Zustand 源码，用伪代码模拟核心逻辑即可。
create(logMiddleware(initializer))这个是基于create(initializer))的增强版，也就是 logMiddleware(initializer)的返回值是类似initializer，initializer 这个函数入参是 set 和 get，返回值不知道是是啥，但通过 initializer(set, get) 可以拿到返回值。
本次写的中间件，是拦截 set 操作，也就是拿到 set 方法，然后包装成一个增强后的 set 方法，这个增强后的 set 方法，会在调用原始 set 方法之前，打印「更新前状态」，在调用原始 set 方法之后，打印「更新后状态」。再把这个增强后的 set 方法传给原始 initializer 函数，执行 initializer 函数，就是返回值了。
// 实现日志中间件（洋葱模型思路）
const logMiddleware = (initializer) => {
return (set, get) => {
// 包装原始set方法，添加日志逻辑
const enhancedSet = async (updater) => {
// 1. 进入阶段：打印更新前状态
console.log('更新前状态：', get());
// 处理异步updater（比如传入的是async函数）
const newState =
typeof updater === 'function'
? await updater(get()) // 等待异步函数执行完
: updater;
// 2. 执行核心逻辑：调用原始set方法更新状态
set(newState);
// 3. 离开阶段：打印更新后状态
console.log('更新后状态：', get());
};
// 将增强后的set传给原始配置（洋葱模型的“next”逻辑）
return initializer(enhancedSet, get);
};
};
- create(initializer) 的本质：initializer 是一个函数，接收 set/get，返回初始状态对象（比如 { count: 0, increment: ... }），create 执行它后会把返回值作为初始 state。
- 中间件的作用链：logMiddleware(initializer) → 返回一个新的初始化函数（我们叫它 enhancedInitializer）；这个 enhancedInitializer 会接收 create 传入的原始 set/get，然后包装 set（比如加日志），再把增强后的 set 传给原始 initializer 执行；最终 create 拿到的是 “增强版 set 执行后返回的状态”，实现对 set 操作的拦截。
- 核心目标：不修改原始 initializer 的逻辑，只通过包装 set/get 实现功能增强 —— 这正是中间件 “开放 - 封闭原则” 的体现。
- 可以说 “中间件是对 initializer 执行逻辑的增强”，但更准确的是：中间件通过包装 set/get 方法，间接增强 initializer 的执行效果——initializer 本身的业务逻辑不变，但它调用的 set 被增强了，最终实现功能扩展。
- 除了 Zustand/Koa，你还知道哪些前端框架 / 库用到了洋葱模型？它在这些场景中解决了什么问题？
还有 express 的中间件，线性执行模型，经典的中间件模式
Express 会把所有 app.use()/app.get() 注册的中间件 / 路由处理函数，按注册顺序存入一个数组，请求到来时依次执行，直到遇到 res.end() 或 next()
// 模拟 Express 的中间件容器
const middlewareStack = [];
// 模拟 app.use()：注册中间件
function use(middleware) {
middlewareStack.push(middleware);
}
// 模拟请求处理：依次执行中间件
function handleRequest(req, res) {
let index = 0; // 记录当前执行的中间件下标
// 定义 next 函数：执行下一个中间件
function next() {
if (index < middlewareStack.length) {
const currentMiddleware = middlewareStack[index];
index++;
currentMiddleware(req, res, next); // 传入 next，让中间件手动调用
}
}
next(); // 启动执行第一个中间件
}
// 使用的时候
// 注册中间件（按顺序）
use((req, res, next) => {
console.log('中间件1：记录请求日志');
next(); // 调用 next 执行下一个
});
use((req, res, next) => {
console.log('中间件2：校验用户身份');
req.user = { id: 1 };
next(); // 调用 next 执行下一个
});
use((req, res, next) => {
console.log('中间件3：处理路由逻辑');
res.end(`Hello ${req.user.id}`); // 没有 next，流程终止
});
// 模拟请求
handleRequest({}, { end: (msg) => console.log('响应：', msg) });
// 输出：
// 中间件1：记录请求日志
// 中间件2：校验用户身份
// 中间件3：处理路由逻辑
// 响应：Hello 1
- 洋葱模型和「责任链模式」有什么区别？请举例说明（比如两者在处理请求时的不同逻辑）。
责任链像工厂的流水线，每个工位（中间件）都做一部分工作，最终产出成品（处理完请求），工位之间是 “接力” 关系。其核心是把多个独立的 “处理环节” 串成一条线，每个环节都是流程的一部分（没有明确的 “主逻辑”）—— 请求从第一个环节流到最后一个环节，每个环节都可能成为 “终点”（比如拦截请求、处理业务）。审批系统的 “员工申请 → 组长审批 → 经理审批 → 财务打款”，每个环节都是流程的必要步骤，没有 “辅助” 之说。
洋葱模型像给核心零件（主逻辑）包保护膜，内层是核心零件，外层的膜（中间件）负责防护、装饰，膜不改变零件本身，只增强功能。洋葱模型的核心是围绕一个明确的 “主逻辑”，用多层辅助逻辑做前后增强—— 主逻辑（如 Koa 的路由处理、Zustand 的 set 操作）是核心，其他中间件都是 “配角”，只负责前置 / 后置的辅助工作（日志、统计、拦截等）。
- 假设你正在开发一个接口请求工具，需要通过中间件实现「请求拦截（加 Token）」「响应拦截（统一处理错误）」「日志记录（打印请求耗时）」，请用洋葱模型设计这三个中间件的执行顺序，并简要说明理由。
function createRequestEnhancer() {
const middlewares = [];
const use = (middlewareFn) => {
middlewares.push(middlewareFn);
};
const executeOnion = async (middlewares, ctx, coreFn) => {
let index = 0;
async function next() {
if (index < middlewares.length) {
// 这里是 < 不是 <=，避免越界
const curMiddleware = middlewares[index];
index++; // 先index++，再执行中间件（否则会重复执行第一个）
await curMiddleware(ctx, next);
} else {
// 核心逻辑：执行fetch并把结果存入ctx
const res = await coreFn(ctx.url, ctx.options);
ctx.response = await res.json(); // 把响应挂载到ctx，供后续中间件使用
}
}
await next();
return ctx.response; // 最终返回响应结果
};
const enhancedFetch = async (url, options = {}) => {
// 加async，支持await
const ctx = { url, options, response: null }; // 初始化response
return await executeOnion(middlewares, ctx, fetch); // 等待executeOnion完成
};
return {
use,
fetch: enhancedFetch,
};
}
10.如果中间件数组很长（比如 100 个），洋葱模型的递归实现会导致栈溢出吗？如果会，如何优化执行器的实现（非递归方式）？
洋葱模型的递归实现（通过 next() 递归调用中间件）在中间件数量极多（比如 1000+）时，会导致栈溢出—— 因为 JavaScript 的调用栈深度有限（通常几千层），每递归一次就会向调用栈压入一层函数，超过阈值就会抛出 Maximum call stack size exceeded 错误。
但如果只是 100 个中间件，递归通常不会溢出（现代浏览器调用栈深度约 10000 层）；但从健壮性角度，非递归实现更可靠。
优化方案：用迭代替代递归实现洋葱执行器
核心思路：把中间件执行逻辑从 “递归调用栈” 改为 “迭代 Promise 链”，通过循环依次执行中间件，利用 Promise 的异步特性避免栈溢出。
/**
* 非递归洋葱执行器
* @param {Array} middlewares - 中间件数组（每个中间件是 (ctx, next) => {}）
* @param {Object} ctx - 上下文对象
* @param {Function} coreFn - 核心逻辑函数
* @returns {Promise} - 执行结果
*/
function onionExecutor(middlewares, ctx, coreFn) {
// 1. 把核心逻辑包装成最后一个“中间件”
let nextMiddleware = async (ctx) => {
await coreFn(ctx);
return ctx;
};
// 2. 从后往前遍历中间件数组，逐个包装成嵌套链
// 比如中间件是 [A,B,C]，遍历顺序是 C → B → A
for (let i = middlewares.length - 1; i >= 0; i--) {
const currentMiddleware = middlewares[i];
// 保存当前的nextMiddleware（下一个要执行的函数）
const prevNext = nextMiddleware;
// 重新定义nextMiddleware：当前中间件包裹prevNext
nextMiddleware = async (ctx) => {
await currentMiddleware(ctx, async () => await prevNext(ctx));
return ctx;
};
}
// 3. 执行最终构建好的链
return nextMiddleware(ctx);
// 从最后一个中间件开始，反向构建Promise链
//也可以用 reduceRight 实现
// return middlewares.reduceRight((nextMiddleware, currentMiddleware) => {
// // currentMiddleware需要调用nextMiddleware（即下一个中间件）
// return async (ctx) => {
// await currentMiddleware(ctx, async () => await nextMiddleware(ctx));
// return ctx;
// };
// }, finalMiddleware)(ctx);
}
用具体例子拆解构建过程（中间件 [A,B,C]）:
假设中间件数组是 [A,B,C]，核心逻辑是 coreFn，我们从后往前遍历
第一步：处理最后一个中间件 C
运行;
// 初始 nextMiddleware 是 coreFn
prevNext = coreFn;
// 把 C 和 coreFn 包装成新的 nextMiddleware
nextMiddleware = (ctx) => C(ctx, () => coreFn(ctx));
第二步：处理中间件 B
// 保存当前的 nextMiddleware（即 C+coreFn）
prevNext = (ctx) => C(ctx, () => coreFn(ctx));
// 把 B 和 C+coreFn 包装成新的 nextMiddleware
nextMiddleware = (ctx) => B(ctx, () => C(ctx, () => coreFn(ctx)));
第三步：处理第一个中间件 A
// 保存当前的 nextMiddleware（即 B+C+coreFn）
prevNext = (ctx) => B(ctx, () => C(ctx, () => coreFn(ctx)));
// 把 A 和 B+C+coreFn 包装成新的 nextMiddleware
nextMiddleware = (ctx) => A(ctx, () => B(ctx, () => C(ctx, () => coreFn(ctx))));
最终得到的 nextMiddleware 就是：A(ctx, () => B(ctx, () => C(ctx, () => coreFn(ctx))))
完整使用示例
// 模拟1000个中间件（测试栈溢出）
const middlewares = Array.from({ length: 1000 }, (_, index) => {
return async (ctx, next) => {
ctx.count += 1;
await next(); // 这里的next是迭代构建的Promise链，非递归
ctx.count += 1;
};
});
// 核心逻辑：修改状态
const coreFn = async (ctx) => {
ctx.value = '核心逻辑执行';
};
// 执行器调用
const ctx = { count: 0, value: '' };
onionExecutor(middlewares, ctx, coreFn).then((res) => {
console.log(res.count); // 2000（每个中间件执行两次count++）
console.log(res.value); // 核心逻辑执行
});
原理说明
- 反向 reduce 构建链：从最后一个中间件开始，用 reduceRight 把中间件嵌套成一个 Promise 链 —— 每个中间件的 next() 指向 “下一个中间件的执行函数”，而非递归调用自身。
- 异步解耦：利用 Promise 的异步特性，每次执行 next() 都是一个新的 Promise，不会压入调用栈，而是进入微任务队列，彻底避免栈溢出。
- 核心逻辑收尾：把核心函数作为最后一个中间件，确保所有中间件执行完后才执行核心逻辑。
登录
