有些專案匯出功能是通過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型別變成亂碼。貼上原文地址：

圖4 在main.js中註釋掉引入mock模組的程式碼

　　其實思路是正確的，但是很容易想到是axios例項的響應攔截器，卻沒有想到是mock！！