express和koa中介軟體是用於處理http請求和響應的，但是二者的設計思路確不盡相同。
express中介軟體乙個接乙個的順序執行, 習慣於將response響應寫在最後乙個中介軟體中；
而koa的中介軟體執行順序是「洋蔥圈」模型。
其實中介軟體也是一種***的思想
我們先看下express中介軟體的執行順序
得到的結果是
下面是koa中介軟體執行順序
const koa = require('koa');
console.log('1111');
await next(); // 呼叫下乙個middleware
console.log('2222');
}); console.log('333');
await next();
console.log('444');
}); await next();
console.log('555');
});
當在下游沒有更多的中介軟體執行後，將會恢復執行其上游的中介軟體
執行的結果是：
結果原因是當我們執行第乙個中介軟體的時候列印出'111'此時 改中介軟體暫停將控制權交給
第二個中介軟體函式，在此說明中介軟體的執行順序很重要在具體業務中有的中介軟體要提前定義
第二個中介軟體的時候列印出'333'此時 中介軟體暫停將控制權交給第3個中介軟體函式，
在第三個中介軟體的時候沒有先列印直接呼叫
awaitnext();
但是沒有其他中介軟體下游沒有更多的中介軟體執行後，將會恢復執行其上游的中介軟體
但是會先列印出555因為這段列印**也包含在最後乙個中介軟體裡面會先執行 以此向上乙個執行列印出 444 在向上乙個執行列印出222 相當於棧先進後出
如果我們改變一下最後乙個中介軟體
//await next(); //注釋這行
console.log('555');
});
列印結果一樣是：所以實際上，express的中介軟體也可以形成「洋蔥圈」模型，在next呼叫後寫的**同樣會執行到，只不過express中一般不會這麼做，因為express的response一般在最後乙個中介軟體，所以其它中介軟體next()後的**影響不到最終結果
redux中介軟體執行原理？
學習過react的同學肯定都用過redux。了解redux資料流機制的action dispatch store reduce 頁面互動其實很好理解，可是當我們要用到非同步請求或者列印日誌之類的副操作的時候，我們無法避免的會用到中介軟體middleware。中介軟體都是怎麼執行以及如何有序的串在一起...
中介軟體 訊息中介軟體學習總結
冪等 在程式設計中.乙個冪等操作的特點是其任意多次執行所產生的影響均與一次執行的影響相同。冪等函式，或冪等方法，是指可以使用相同引數重複執行，並能獲得相同結果的函式。這些函式 不會影響系統狀態，也不用擔心重複執行會對系統造成改變。例如，getusername 和settrue 函式就是乙個冪等函式....
Django中介軟體的執行順序
middleware並不是django所獨有的東西，在其他的web框架中也有這種概念。在django中，middleware可以滲入處理流程的四個階段 request，view，response和exception，相應的，在每個middleware類中都有process request，proce...