先說說請求攔截的情況：

在單頁應(yīng)用中，如果需要保存用戶信息基本上需要維護(hù)一個 token （或者說類似的東西），這個 token 是需要跟隨請求給到后端，這時候就會把請求攔截下來，動態(tài)的注入 token 。一些固定的請求頭信息，會用到這種情況。還有一種，就是你們公司有固定的請求參數(shù)接收方式（怪異的接收方式），但是你又想正常寫成json的形式，那么請求攔截也會有用，用于轉(zhuǎn)化參數(shù)傳遞方式。

接著說說響應(yīng)攔截的情況：

restful api 是不會出現(xiàn)請求錯誤重定向的問題的，也就是說即使請求出錯，后端也會是正常響應(yīng)的，只不錯是會提供給你一個錯誤碼，這時候，攔截響應(yīng)就能處理后端響應(yīng)回來的錯誤碼，然后進(jìn)行對應(yīng)的操作，比如提示錯誤信息等等。當(dāng)然同樣的也可以處理數(shù)據(jù)，比如你們公司返回回來一種怪異的數(shù)據(jù)格式（不是json），就可以處理成前端友好的格式（json）。

最后提供給你一個使用 axios 的終極方式

其實這里說的發(fā)送前后攔截數(shù)據(jù)的問題在日常開發(fā)是經(jīng)常發(fā)生的情景，我下面列一下常見情景：

• 后端返回的數(shù)據(jù)不適合前端UI組件直接使用
• UI組件使用的結(jié)構(gòu)與后端接收的數(shù)據(jù)不同時（比如tree組件）
• 上傳圖片前的壓制處理

當(dāng)然咯還有一下日常補(bǔ)?。ê蠖巳鄙僮侄蔚惹闆r）的處理都需要攔截數(shù)據(jù)然后補(bǔ)全（或修改）。

發(fā)送時候，清空無用字段，接受時候，全局對接口判錯，進(jìn)行彈窗處理，比如code 0 成功，code -1 失敗，提示失敗原因，code -2 沒登錄或者權(quán)限，跳登陸

在大量請求需要用到同一個字段的時候

我舉一個比較常見的場景吧。ajax請求的全局loading組件的顯示與否。

網(wǎng)站上有個全局的loading組件（一個小圈圈放在了右上角，相對屏幕定位）。
這東西就是當(dāng)有ajax發(fā)出的時候顯示，沒有ajax請求的時候不顯示。

這東西你總不能給每個有ajax請求的地方都寫上顯示/隱藏的代碼吧，這就要做全局的攔截了。

還有一種情況是——錯誤處理。
你和后端約定了一套錯誤碼，后端返回對應(yīng)的錯誤碼，前端顯示報錯。
你也可能給每個ajax后面都帶上一樣的錯誤處理函數(shù)，沒有必要，這也是需要做返回攔截的，對發(fā)生錯誤的情況做統(tǒng)一處理。

攔截器的作用：封裝了用戶每次請求數(shù)據(jù)公共部分，比如說一些放在緩存的數(shù)據(jù),如token，headers設(shè)置，接收類型等，
圖1是請求攔截器，圖2是響應(yīng)攔截器，根據(jù)后臺返回的status，提前封裝判斷是成功還是錯誤，至于錯誤又是什么錯誤，以提示框來提醒使用者；