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