TA貢獻1815條經驗 獲得超13個贊
我舉一個比較常見的場景吧。ajax請求的全局loading組件的顯示與否。
網站上有個全局的loading組件（一個小圈圈放在了右上角，相對屏幕定位）。
這東西就是當有ajax發出的時候顯示，沒有ajax請求的時候不顯示。
這東西你總不能給每個有ajax請求的地方都寫上顯示/隱藏的代碼吧，這就要做全局的攔截了。
還有一種情況是——錯誤處理。
你和后端約定了一套錯誤碼，后端返回對應的錯誤碼，前端顯示報錯。
你也可能給每個ajax后面都帶上一樣的錯誤處理函數，沒有必要，這也是需要做返回攔截的，對發生錯誤的情況做統一處理。
TA貢獻1868條經驗 獲得超4個贊
其實這里說的發送前后攔截數據的問題在日常開發是經常發生的情景，我下面列一下常見情景：
后端返回的數據不適合前端UI組件直接使用
UI組件使用的結構與后端接收的數據不同時（比如tree組件）
上傳圖片前的壓制處理
當然咯還有一下日常補?。ê蠖巳鄙僮侄蔚惹闆r）的處理都需要攔截數據然后補全（或修改）。
TA貢獻1859條經驗 獲得超6個贊
先說說請求攔截的情況：
在單頁應用中，如果需要保存用戶信息基本上需要維護一個 token （或者說類似的東西），這個 token 是需要跟隨請求給到后端，這時候就會把請求攔截下來，動態的注入 token 。一些固定的請求頭信息，會用到這種情況。還有一種，就是你們公司有固定的請求參數接收方式（怪異的接收方式），但是你又想正常寫成json的形式，那么請求攔截也會有用，用于轉化參數傳遞方式。
接著說說響應攔截的情況：
restful api 是不會出現請求錯誤重定向的問題的，也就是說即使請求出錯，后端也會是正常響應的，只不錯是會提供給你一個錯誤碼，這時候，攔截響應就能處理后端響應回來的錯誤碼，然后進行對應的操作，比如提示錯誤信息等等。當然同樣的也可以處理數據，比如你們公司返回回來一種怪異的數據格式（不是json），就可以處理成前端友好的格式（json）。
TA貢獻2041條經驗 獲得超4個贊
TA貢獻1828條經驗 獲得超3個贊
攔截器的作用：封裝了用戶每次請求數據公共部分，比如說一些放在緩存的數據,如token，headers設置，接收類型等，
圖1是請求攔截器，圖2是響應攔截器，根據后臺返回的status，提前封裝判斷是成功還是錯誤，至于錯誤又是什么錯誤，以提示框來提醒使用者；
舉報