目錄

• 背景是：
• 會造成什麼情況呢？

背景是：

在實際開發中，可能會遇到網路問題或者查詢量比較大的情況，上一個請求還沒有完成，使用者就發起了下一個請求。

會造成什麼情況呢？

但是同一個請求多次傳送到伺服器，無疑是對伺服器的一種壓力，所以需要在已經優化伺服器過查詢速度後，以及使用者網路情況比較差的條件下，在前端進行請求限制。

axios 自帶的cancelToken可以幫我們實現這個需求，並且提供給了我們一個現成的api axios.CancelToken ，這是一個返回值是帶有請求資訊的回撥函式，我們可以在需要cancel的時候去執行這個回撥函式。具體實現如下：

const service = axios.create({});
const penddingMap = new Map();
const addPendding = (config) => {
 config.cancelToken = config.cancelToken || newwww.cppcns.com
 
 axios.CancelToken(cancel => {
  if(!penddingMap.has(config.url)){
   penddingMap.set(config.url,cancel);
  }
 })
}

const removePendding = (config) => {
 if(penddingMap.has(config.url)){
  leWDTkUVt cancel = penddingMap.get(config.url);
    cancel(config.url);
    penddingMap.delete(config.url)
 }
}

本地維護一個Map來儲存每個請求資訊， addPendding 中每次會去先判斷是否有cancelToken，如果有就不用重新建立一個cancelToken。 removePendding 中判斷請求資訊是否在Map中，如果該請求存在於Map中，則執行cancel函式，並刪除Map中的該請求。

攔截器中的具體應用：

service.interceptors.request.use(config => {
 removePending(config) // 如果存在Map中先cancel該請求
  addPendding(config)  // 新增該請求到Map中
  return config
})

service.interceptors.response.use(response => {
 ``` // some code
  return response.data
}，error => {
 // 捕獲cancel請求並丟擲
  if(error instanceof Cancel){
    error.message = '上一請求尚未結束，稍等~';
    Message.error(error.message);
    ret客棧
 
urn Promise.reject(error.response) 
  // 這裡丟擲需要注意，在請求時呼叫try-catch進行捕獲
  })
)

這裡攔截成功後，就可以限制住大流量的多次請求。

這裡只是一個例子，也可以通過判斷按鈕邏輯來控制使用者是否發起請求。

到此這篇關於實現axios限制請求佇列的文章就介紹到這了,更多相關js axios限制請求佇列內容請搜尋我們以前的文章或繼續瀏覽下面的相關文章希望大家以後多多支援我們！