Koa 是當下主流 NodeJS 框架，以輕量見長，而它中介軟體機制與相對傳統的 Express 支援了非同步，所以編碼時經常使用 async/await，提高了可讀性，使程式碼變得更優雅，上一篇文章 NodeJS 進階 —— Koa 原始碼分析，也對 “洋蔥模型” 和實現它的 compose 進行分析，由於個人覺得 compose 的程式設計思想比較重要，應用廣泛，所以本篇藉著 “洋蔥模型” 的話題，打算用四種方式來實現 compose。

洋蔥模型案例

如果你已經使用 Koa 對 “洋蔥模型” 這個詞一定不陌生，它就是 Koa 中介軟體的一種序列機制，並且是支援非同步的，下面是一個表達 “洋蔥模型” 的經典案例。

const Koa = require("koa");const app = new Koa();app.use(async (ctx, next) => { console.log(1); await next(); console.log(2);});app.use(async (ctx, next) => { console.log(3); await next(); console.log(4);});app.use(async (ctx, next) => { console.log(5); await next(); console.log(6);});app.listen(3000);

上面的寫法我們按照官方推薦，使用了 async/await，但如果是同步程式碼不使用也沒有關係，這裡簡單的分析一下執行機制，第一個中介軟體函式中如果執行了 next，則下一個中介軟體會被執行，依次類推，就有了我們上面的結果，而在 Koa 原始碼中，這一功能是靠一個 compose 方法實現的，我們本文四種實現 compose 的方式中實現同步和非同步，並附帶對應的案例來驗證。

準備工作

在真正建立 compose 方法之前應該先做些準備工作，比如建立一個 app 物件來頂替 Koa 創建出的例項物件，並新增 use 方法和管理中介軟體的陣列 middlewares。

檔案：app.js

\t// 模擬 Koa 建立的例項const app = { middlewares: []};// 建立 use 方法app.use = function(fn) { app.middlewares.push(fn);};// app.compose.....module.exports = app;

上面的模組中匯出了 app 物件，並建立了儲存中介軟體函式的 middlewares 和新增中介軟體的 use 方法，因為無論用哪種方式實現 compose 這些都是需要的，只是 compose 邏輯的不同，所以後面的程式碼塊中會只寫 compose 方法。

Koa 中 compose 的實現方式

首先介紹的是 Koa 原始碼中的實現方式，在 Koa 原始碼中其實是通過 koa-compose 中介軟體來實現的，我們在這裡將這個模組的核心邏輯抽取出來，用我們自己的方式實現，由於重點在於分析 compose 的原理，所以 ctx 引數就被去掉了，因為我們不會使用它，重點是 next 引數。

同步的實現

檔案：app.js

app.compose = function() { // 遞迴函式 function dispatch(index) { // 如果所有中介軟體都執行完跳出 if (index === app.middlewares.length) return; // 取出第 index 箇中間件並執行 const route = app.middlewares[index]; return route(() => dispatch(++index)); } // 取出第一個中介軟體函式執行 dispatch(0);}

上面是同步的實現，通過遞迴函式 dispatch 的執行取出了陣列中的第一個中介軟體函式並執行，在執行時傳入了一個函式，並遞迴執行了 dispatch，傳入的引數 +1，這樣就執行了下一個中介軟體函式，依次類推，直到所有中介軟體都執行完畢，不滿足中介軟體執行條件時，會跳出，這樣就按照上面案例中 1 3 5 6 4 2 的情況執行，測試例子如下（同步上、非同步下）。

檔案：sync-test.js

const app = require("./app");app.use(next => { console.log(1); next(); console.log(2);});app.use(next => { console.log(3); next(); console.log(4);});app.use(next => { console.log(5); next(); console.log(6);});app.compose();

檔案：async-test.js

const app = require("./app");// 非同步函式function fn() { return new Promise((resolve, reject) => { setTimeout(() => { resolve(); console.log("hello"); }, 3000); });}app.use(async next => { console.log(1); await next(); console.log(2);});app.use(async next => { console.log(3); await fn(); // 呼叫非同步函式 await next(); console.log(4);});app.use(async next => { console.log(5); await next(); console.log(6);});app.compose();

我們發現如果案例中按照 Koa 的推薦寫法，即使用 async 函式，都會通過，但是在給 use 傳參時可能會傳入普通函式或 async 函式，我們要將所有中介軟體的返回值都包裝成 Promise 來相容兩種情況，其實在 Koa 中 compose 最後返回的也是 Promise，是為了後續的邏輯的編寫，但是現在並不支援，下面來解決這兩個問題。

注意：後面 compose 的其他實現方式中，都是使用 sync-test.js 和 async-test.js 驗證，所以後面就不再重複了。

升級為支援非同步

檔案：app.js

app.compose = function() { // 遞迴函式 function dispatch(index) { // 如果所有中介軟體都執行完跳出，並返回一個 Promise if (index === app.middlewares.length) return Promise.resolve(); // 取出第 index 箇中間件並執行 const route = app.middlewares[index]; // 執行後返回成功態的 Promise return Promise.resolve(route(() => dispatch(++index))); } // 取出第一個中介軟體函式執行 dispatch(0);}

我們知道 async 函式中 await 後面執行的非同步程式碼要實現等待，帶非同步執行後繼續向下執行，需要等待 Promise，所以我們將每一箇中間件函式在呼叫時最後都返回了一個成功態的 Promise，使用 async-test.js 進行測試，發現結果為 1 3 hello(3s後) 5 6 4 2。

Redux 舊版本 compose 的實現方式

同步的實現

檔案：app.js

app.compose = function() { return app.middlewares.reduceRight((a, b) => () => b(a), () => {})();}

上面的程式碼看起來不太好理解，我們不妨根據案例把這段程式碼拆解開，假設 middlewares 中儲存的三個中介軟體函式分別為 fn1、fn2 和 fn3，由於使用的是 reduceRight 方法，所以是逆序歸併，第一次 a 代表初始值（空函式），b 代表 fn3，而執行 fn3 返回了一個函式，這個函式再作為下一次歸併的 a，而 fn2 作為 b，依次類推，過程如下。

// 第 1 次 reduceRight 的返回值，下一次將作為 a() => fn3(() => {});// 第 2 次 reduceRight 的返回值，下一次將作為 a() => fn2(() => fn3(() => {}));// 第 3 次 reduceRight 的返回值，下一次將作為 a() => fn1(() => fn2(() => fn3(() => {})));

由上面的拆解過程可以看出，如果我們呼叫了這個函式會先執行 fn1，如果呼叫 next 則會執行 fn2，如果同樣呼叫 next 則會執行 fn3，fn3 已經是最後一箇中間件函數了，再次調 next 會執行我們最初傳入的空函式，這也是為什麼要將 reduceRight 的初始值設定成一個空函式，就是防止最後一箇中間件呼叫 next 而報錯。

經過測試上面的程式碼不會出現順序錯亂的情況，但是在 compose 執行後，我們希望進行一些後續的操作，所以希望返回的是 Promise，而我們又希望傳入給 use 的中介軟體函式既可以是普通函式，又可以是 async 函式，這就要我們的 compose 完全支援非同步。

升級為支援非同步

檔案：app.js

app.compose = function() {

return Promise.resolve(

app.middlewares.reduceRight(

(a, b) => () => Promise.resolve(b(a)),

() => Promise.resolve()

)()

);

}

參考同步的分析過程，由於最後一箇中間件執行後執行的空函式內一定沒有任何邏輯，但為遇到非同步程式碼可以繼續執行（比如執行 next 後又呼叫了 then），都處理成了 Promise，保證了 reduceRight 每一次歸併的時候返回的函式內都返回了一個 Promise，這樣就完全相容了 async 和普通函式，當所有中介軟體執行完畢，也返回了一個 Promise，這樣 compose 就可以呼叫 then 方法執行後續邏輯。

Redux 新版本 compose 的實現方式

同步的實現

檔案：app.js

app.compose = function() { return app.middlewares.reduce((a, b) => arg => a(() => b(arg)))(() => {});}

Redux 新版本中將 compose 的邏輯做了些改動，將原本的 reduceRight 換成 reduce，也就是說將逆序歸併改為了正序，我們不一定和 Redux 原始碼完全相同，是根據相同的思路來實現序列中介軟體的需求。

個人覺得改成正序歸併後更難理解，所以還是將上面程式碼結合案例進行拆分，中介軟體依然是 fn1、fn2 和 fn3，由於 reduce 並沒有傳入初始值，所以此時 a 為 fn1，b 為 fn2。

// 第 1 次 reduce 的返回值，下一次將作為 aarg => fn1(() => fn2(arg));// 第 2 次 reduce 的返回值，下一次將作為 aarg => (arg => fn1(() => fn2(arg)))(() => fn3(arg));// 等價於...arg => fn1(() => fn2(() => fn3(arg)));// 執行最後返回的函式連線中介軟體，返回值等價於...fn1(() => fn2(() => fn3(() => {})));

所以在呼叫 reduce 最後返回的函式時，傳入了一個空函式作為引數，其實這個引數最後傳遞給了 fn3，也就是第三個中介軟體，這樣保證了在最後一箇中間件呼叫 next 時不會報錯。

升級為支援非同步

下面有個更艱鉅的任務，就是將上面的程式碼更改為支援非同步，實現如下。

檔案：app.js

app.compose = function() { return Promise.resolve( app.middlewares.reduce((a, b) => { return arg => a(() => Promise.resolve(b(arg))); })(() => Promise.resolve()) );}

實現非同步其實與逆序歸併是一個套路，就是讓每一箇中間件函式的返回值都是 Promise，並讓 compose 也返回 Promise。

使用 async 函式實現

這個版本是我在之前在學習 Koa 原始碼時偶然在一位大佬的一篇分析 Koa 原理的文章中看到的（翻了半天實在沒找到連結），在這裡也拿出來和大家分享一下，由於是利用 async 函式實現的，所以預設就是支援非同步的，因為 async 函式會返回一個 Promise。

檔案：app.js

app.compose = function() { // 自執行 async 函式返回 Promise return (async function () { // 定義預設的 next，最後一箇中間件內執行的 next let next = async () => Promise.resolve(); // middleware 為每一箇中間件函式，oldNext 為每個中介軟體函式中的 next // 函式返回一個 async 作為新的 next，async 執行返回 Promise，解決非同步問題 function createNext(middleware, oldNext) { return async () => { await middleware(oldNext); } } // 反向遍歷中介軟體陣列，先把 next 傳給最後一箇中間件函式 // 將新的中介軟體函式存入 next 變數 // 呼叫下一個中介軟體函式，將新生成的 next 傳入 for (let i = app.middlewares.length - 1; i >= 0; i--) { next = createNext(app.middlewares[i], next); } await next(); })();}

上面程式碼中的 next 是一個只返回成功態 Promise 的函式，可以理解為其他實現方式中最後一箇中間件呼叫的 next，而陣列 middlewares 剛好是反向遍歷的，取到的第一個值就是最後一箇中間件，而呼叫 createNext 作用是返回一個新的可以執行陣列中最後一箇中間件的 async 函式，並傳入了初始的 next，這個返回的 async 函式作為新的 next，再取到倒數第二個中介軟體，呼叫 createNext，又返回了一個 async 函式，函式內依然是倒數第二個中介軟體的執行，傳入的 next 就是上次新生成的 next，這樣依次類推到第一個中介軟體。

因此執行第一個中介軟體返回的 next 則會執行傳入的上一個生成的 next 函式，就會執行第二個中介軟體，就會執行第二個中介軟體中的 next，就這樣直到執行完最初定義的 next，通過案例的驗證，執行結果與洋蔥模型完全相同。

至於非同步的問題，每次執行的 next 都是 async 函式，執行後返回的都是 Promise，而最外層的自執行 async 函式返回的也是 Promise，也就是說 compose 最後返回的是 Promise，因此完全支援非同步。