從業務上簡單說，凡是code不是200的，都是異常。這裏code可以是HTTP狀態碼，也可以是響應體的code，就不細究了，反正本質沒差別。然後，根據code的不同，又可以細分成401 403 404 500等等。
如果妳的後端夥伴以HTTP狀態碼表示404，以響應體code表示其他錯誤，而且妳又無法勸說他們，那麽妳應在axios的攔截器裏把各種情況全考慮進去，比如：
超時很簡單，axios也支持，設定超時閾值即可。超時跟無響應的區別是，超時意味著HTTP三次握手成功，但是得不到響應體，瀏覽器知道接口是存在的，但是響應體又在規定時間內沒有拿到。無響應是根本無法HTTP握手，也就無法獲知接口存在。
處理超時，通常做法是在攔截器裏重新請求壹遍，還是超時的話就視為服務器錯誤。
得不到響應又分成2種，可能是網斷了，也可能是服務器停機了。
苛刻地說，妳應分辨這2種情況，並給出不同的提示，畢竟網斷了，用戶可以尋找別的聯網方式，而服務器停機了就給個重連按鈕，讓用戶有事沒事的嘗試重連壹下。
關於解決方案，首先說，XHR對象無法區分到底斷網還是服務器停機，axios對於2種情況都返回'Network Error'。在得到這個反饋之後，妳接下來可以有這2種解決辦法：
妳可以將 /images/blank.gif 改成其他服務器穩定且字節小的圖片。或許妳可以做壹張幾字節的圖片，傳到壹個非常牛逼的CDN上。
MDN手冊： https://developer.mozilla.org/zh-CN/docs/Web/API/Navigator/connection
它不支持IE，就算妳不在乎這壹點，那麽它是不是壹定準呢？對於需要登錄的VPN網絡，它是否準呢？我也不知道，總體說，它真的不是最佳的方案。我推薦用方案1。
很簡單，分為3種：
通常，壹個接口，只需要按照其中壹種去處理即可，優先級就是上面書寫順序。
容器內錯誤提示肯定是內容區的接口出錯才會出現。
處理方式：
局部報錯比較容易理解，比如壹個List的接口出錯，那麽，上策是應當給這個容器盡量撐高到有內容時的高度，然後居中給壹個錯誤圖標和錯誤描述。中策是不考慮有內容時候的高度，只讓錯誤提示和錯誤描述撐起壹定高度即可。都不算錯。如果容器很小，比如就是壹個3位數值，那麽用壹個 - 表示錯誤也可以。
頁面整體報錯稍微復雜，比如壹個左右結構的內容管理系統，前置接口有userInfo接口、全局字典接口、全局路由接口等，這些接口與眾不同的地方在於它們是基礎接口，它們出錯的話，網站幹脆就不能用，頁面骨架也是錯亂的，這種情況下可以有2種解決辦法：壹是跳轉到專門的5xx報錯頁面，頁面中央有錯誤圖標、錯誤提示，以及“返回上壹頁”的按鈕；二是用白板遮罩覆蓋瀏覽器視口，居中放壹個錯誤圖標和錯誤文字以及“刷新頁面”的按鈕，本質是用壹個fixed的遮罩壓住瀏覽器全部面積。用哪種方案都可。所以妳要做的是決定哪些接口屬於全局報錯，哪些接口屬於局部報錯，並做不同的處理。
報錯內容：
根據ajax異常的分類，可能至少能分出3種：網絡錯誤、服務器宕機、服務器錯誤。具體用什麽圖標和文字我就不多說了。
組件化：
容器內報錯應盡量組件化。該放返回上壹頁或刷新按鈕的，壹定要放按鈕。
排他性：
只要做了容器內報錯，就不要做另外報錯了。這也說明了壹點，就是在axios攔截器裏彈toast或者modal是愚蠢的方案，我在別的文章也提到過這種觀點。不做容器內報錯的情況，才應該考慮其他3種情況。
什麽樣的場景下使用容器隱藏？
比如頁面有壹個角落顯示妳的粉絲數、關註數、評論量……。如果有獲取到數據，則讓這個容器出現，沒有的話，則容器就保持隱藏。這壹類場景往往應用於非主要內容，比如側邊欄的小內容塊。
由於這只適用於非主要內容，那麽主要內容也會有它自己的報錯，所以，妳不必擔心用戶看不到“網絡出錯”這類錯誤提示。
先簡單對比壹下toast和modal。
很簡單，toast就是輕提示，不需要手動關閉，modal就是重提示，需要手動關閉。采用哪個，只要站在用戶角度思考問題就好了。比如有人說，異常應當用重提示。可以這麽絕對化麽？不可以。比如妳在某個頁面點贊，提示妳 “您已經點過贊了” ，這用重提示嗎？肯定toast就夠了。同樣的，成功提示壹定用輕提示嗎？比如提示 “感謝參與，工作人員將在3~5個工作日內聯系妳” ，這麽長，能toast？能壹閃而過？
什麽接口適用彈出提示？簡單說，只要跟UI顯示不相幹的，都最好是使用彈出提示。比如這幾種場景：
先說上傳數據斷網之類的錯誤，通常用modal，因為modal能夠攔截用戶動作，避免重復上傳，而且，還能給用戶足夠的時間讓用戶看清楚出錯原因，避免無謂的重試。
然後說數據內容錯誤，無論是表單提交，還是點個贊，錯誤提示壹般用toast，畢竟用戶可能只是不小心填錯的，看壹眼然後趕緊改正就好了。
最後說401錯誤，有2種做法，壹是用modal，因為壹般要強制用戶轉到登錄頁，但是轉之前也得讓用戶看明白為什麽要轉，所以可以先modal提示，點擊確定就跳轉到登錄頁；二是用toast，但是需要先跳轉，然後在登錄頁上提示toast“請先登錄”。
警告條
警告條是可關閉的、永久生命的、又不妨礙用戶繼續操作的彈出組件，壹般在頁面頂部，或者在用戶操作區域的附近。什麽場景用警告條？
比如的MD編輯器，妳只要輸入，就會自動給服務器發送數據，頻率很快，有時候因為網絡或者服務器的問題，會出現保存失敗的可能性，這時候就會在頁面頂部出現壹個比較長時間的警告條，告訴妳保存失敗，但妳依然可以繼續寫，什麽時候網絡正常了，什麽時候toast才會自動消失，當然妳也可以手動關閉它。
總之，toast、modal、警告條究竟什麽場合使用，要根據產品、業務具體而定，要註意優先使用容器內報錯和容器隱藏。