有些項目導出功能是通過Blob對象實現的，代碼差不多可能大概類似長這個樣子：
var params={ XX:xx, } this.$axios.get('/XXX/XXX',{ params: params, responseType: 'blob' }).then(res => { console.log(res); });
其中，關鍵語句就是responseType。它表示的是服務器響應的數據類型，正常能獲取到的響應體res打印出來大致是這樣的，如圖1所示：
圖1 正確的Blob對象
但是如果設置了responseType還是獲取不到正常的Blob對象，控制檯打印出來類似下面這樣的亂碼，如圖2所示：
圖2 “不正常”的Blob對象，出現亂碼
如果後端走Postman是可以成功下載排除了是後端的鍋的話，這個時候就要注意前端項目中是否用了mock模塊。mock.js原本是爲了攔截請求，生成隨機數據，讓前端獨立於後端進行開發。但是打開node_modules下mockjs的mock.js源碼，大概在8400行左右有這樣一段代碼，如圖3所示。可以看到這個方法是用來初始化Response的，只要項目裏包含了這個模塊，每次項目啓動初始化的時候，就會給響應攔截的responseType修改爲' '。所以導致了我們原先設置的responseType:'blob'無效，也就進而導致了接收二進制流出現亂碼。
圖3 mock.js源碼初始化Response的方法
當時，我們接收到亂碼之後，前端查，後端查，後端查完，前端查，前後端都找了很久，就是沒有找到問題所在。我反覆看了Axios和WebAPI官方文檔中關於Blob對象的相關配置，我覺得我的前端代碼肯定沒有問題，但是後端也通過走Postman已經排除了自己的“嫌疑”，所以，這個鍋還得前端背。我當時覺得既然不是這一塊代碼的問題，是不是因爲某種東西改變了響應頭的結構，這樣就很容易想到axios裏的響應攔截器，但是查看了下並沒有這樣的代碼。然後就面向百度編程，終於在思否論壇裏找到一個可能性：mock模塊會影響原生的ajax請求，使得服務器返回的blob類型變成亂碼。貼上原文地址：https://segmentfault.com/q/1010000014704618/。瞬間豁然開朗，打開入口文件main.js，註釋掉相關代碼，僅僅兩個“//”，立馬解決問題，如圖4所示。
圖4 在main.js中註釋掉引入mock模塊的代碼
其實思路是正確的，但是很容易想到是axios實例的響應攔截器，卻沒有想到是mock！！