axios如何利用promise無痛刷新token

需求

最近遇到個需求：前端登錄後，後端返回token和token有效時間，當token過期時要求用舊token去獲取新的token，前端需要做到無痛刷新token，即請求刷新token時要做到用戶無感知。

需求解析

當用戶發起一個請求時，判斷token是否已過期，若已過期則先調refreshToken接口，拿到新的token後再繼續執行之前的請求。

這個問題的難點在於：當同時發起多個請求，而刷新token的接口還沒返回，此時其他請求該如何處理？接下來會循序漸進地分享一下整個過程。

實現思路

由於後端返回了token的有效時間，可以有兩種方法：

方法一：

在請求發起前攔截每個請求，判斷token的有效時間是否已經過期，若已過期，則將請求掛起，先刷新token後再繼續請求。

方法二：

不在請求前攔截，而是攔截返回後的數據。先發起請求，接口返回過期後，先刷新token，再進行一次重試。

兩種方法對比

方法一

優點：在請求前攔截，能節省請求，省流量。
缺點：需要後端額外提供一個token過期時間的字段；使用了本地時間判斷，若本地時間被篡改，特別是本地時間比服務器時間慢時，攔截會失敗。

PS：token有效時間建議是時間段，類似緩存的MaxAge，而不要是絕對時間。當服務器和本地時間不一致時，絕對時間會有問題。

方法二

優點：不需額外的token過期字段，不需判斷時間。
缺點：會消耗多一次請求，耗流量。

綜上，方法一和二優缺點是互補的，方法一有校驗失敗的風險（本地時間被篡改時，當然一般沒有用戶閒的蛋疼去改本地時間的啦），方法二更簡單粗暴，等知道服務器已經過期了再重試一次，只是會耗多一個請求。

在這裏博主選擇了 方法二。

實現

這裏會使用axios來實現，方法一是請求前攔截，所以會使用axios.interceptors.request.use()這個方法；

而方法二是請求後攔截，所以會使用axios.interceptors.response.use()方法。

封裝axios基本骨架

首先說明一下，項目中的token是存在localStorage中的。request.js基本骨架:

import axios from 'axios'

// 從localStorage中獲取token
function getLocalToken () {
    const token = window.localStorage.getItem('token')
    return token
}


// 給實例添加一個setToken方法，用於登錄後將最新token動態添加到header，同時將token保存在localStorage中
instance.setToken = (token) => {
  instance.defaults.headers['X-Token'] = token
  window.localStorage.setItem('token', token)
}

// 創建一個axios實例
const instance = axios.create({
  baseURL: '/api',
  timeout: 300000,
  headers: {
    'Content-Type': 'application/json',
    'X-Token': getLocalToken() // headers塞token
  }
})

// 攔截返回的數據
instance.interceptors.response.use(response => {
  // 接下來會在這裏進行token過期的邏輯處理
  return response
}, error => {
  return Promise.reject(error)
})

export default instance

這個是項目中一般的axios實例的封裝，創建實例時，將本地已有的token放進header，然後export出去供調用。接下來就是如何攔截返回的數據啦。

instance.interceptors.response.use攔截實現

後端接口一般會有一個約定好的數據結構，如：

{code: 1234, message: 'token過期', data: {}}

如我這裏，後端約定當code === 1234時表示token過期了，此時就要求刷新token。

instance.interceptors.response.use(response => {
  const { code } = response.data
  if (code === 1234) {
    // 說明token過期了,刷新token
    return refreshToken().then(res => {
      // 刷新token成功，將最新的token更新到header中，同時保存在localStorage中
      const { token } = res.data
      instance.setToken(token)
      // 獲取當前失敗的請求
      const config = response.config
      // 重置一下配置
      config.headers['X-Token'] = token
      config.baseURL = '' // url已經帶上了/api，避免出現/api/api的情況
      // 重試當前請求並返回promise
      return instance(config)
    }).catch(res => {
      console.error('refreshtoken error =>', res)
      //刷新token失敗，神仙也救不了了，跳轉到首頁重新登錄吧
      window.location.href = '/'
    })
  }
  return response
}, error => {
  return Promise.reject(error)
})

function refreshToken () {
    // instance是當前request.js中已創建的axios實例
    return instance.post('/refreshtoken').then(res => res.data)
}

這裏需要額外注意的是，response.config就是原請求的配置，但這個是已經處理過了的，config.url已經帶上了baseUrl，因此重試時需要去掉，同時token也是舊的，需要刷新下。

以上就基本做到了無痛刷新token，當token正常時，正常返回，當token已過期，則axios內部進行一次刷新token和重試。對調用者來說，axios內部的刷新token是一個黑盒，是無感知的，因此需求已經做到了。

問題和優化

上面的代碼還是存在一些問題的，沒有考慮到多次請求的問題，因此需要進一步優化。

如何防止多次刷新token

如果refreshToken接口還沒返回，此時再有一個過期的請求進來，上面的代碼就會再一次執行refreshToken，這就會導致多次執行刷新token的接口，因此需要防止這個問題。我們可以在request.js中用一個flag來標記當前是否正在刷新token的狀態，如果正在刷新則不再調用刷新token的接口。

// 是否正在刷新的標記
let isRefreshing = false
instance.interceptors.response.use(response => {
  const { code } = response.data
  if (code === 1234) {
    if (!isRefreshing) {
      isRefreshing = true
      return refreshToken().then(res => {
        const { token } = res.data
        instance.setToken(token)
        const config = response.config
        config.headers['X-Token'] = token
        config.baseURL = ''
        return instance(config)
      }).catch(res => {
        console.error('refreshtoken error =>', res)
        window.location.href = '/'
      }).finally(() => {
        isRefreshing = false
      })
    }
  }
  return response
}, error => {
  return Promise.reject(error)
})

這樣子就可以避免在刷新token時再進入方法了。但是這種做法是相當於把其他失敗的接口給捨棄了，假如同時發起兩個請求，且幾乎同時返回，第一個請求肯定是進入了refreshToken後再重試，而第二個請求則被丟棄了，仍是返回失敗，所以接下來還得解決其他接口的重試問題。

同時發起兩個或以上的請求時，其他接口如何重試

兩個接口幾乎同時發起和返回，第一個接口會進入刷新token後重試的流程，而第二個接口需要先存起來，然後等刷新token後再重試。同樣，如果同時發起三個請求，此時需要緩存後兩個接口，等刷新token後再重試。由於接口都是異步的，處理起來會有點麻煩。

當第二個過期的請求進來，token正在刷新，我們先將這個請求存到一個數組隊列中，想辦法讓這個請求處於等待中，一直等到刷新token後再逐個重試清空請求隊列。
那麼如何做到讓這個請求處於等待中呢？爲了解決這個問題，我們得藉助Promise。將請求存進隊列中後，同時返回一個Promise，讓這個Promise一直處於Pending狀態（即不調用resolve），此時這個請求就會一直等啊等，只要我們不執行resolve，這個請求就會一直在等待。當刷新請求的接口返回來後，我們再調用resolve，逐個重試。最終代碼：

// 是否正在刷新的標記
let isRefreshing = false
// 重試隊列，每一項將是一個待執行的函數形式
let requests = []

instance.interceptors.response.use(response => {
  const { code } = response.data
  if (code === 1234) {
    const config = response.config
    if (!isRefreshing) {
      isRefreshing = true
      return refreshToken().then(res => {
        const { token } = res.data
        instance.setToken(token)
        config.headers['X-Token'] = token
        config.baseURL = ''
        // 已經刷新了token，將所有隊列中的請求進行重試
        requests.forEach(cb => cb(token))
        // 重試完了別忘了清空這個隊列（掘金評論區同學指點）
        requests = []
        return instance(config)
      }).catch(res => {
        console.error('refreshtoken error =>', res)
        window.location.href = '/'
      }).finally(() => {
        isRefreshing = false
      })
    } else {
      // 正在刷新token，返回一個未執行resolve的promise
      return new Promise((resolve) => {
        // 將resolve放進隊列，用一個函數形式來保存，等token刷新後直接執行
        requests.push((token) => {
          config.baseURL = ''
          config.headers['X-Token'] = token
          resolve(instance(config))
        })
      })
    }
  }
  return response
}, error => {
  return Promise.reject(error)
})

這裏可能比較難理解的是requests這個隊列中保存的是一個函數，這是爲了讓resolve不執行，先存起來，等刷新token後更方便調用這個函數使得resolve執行。至此，問題應該都解決了。

最後完整代碼

import axios from 'axios'

// 從localStorage中獲取token
function getLocalToken () {
    const token = window.localStorage.getItem('token')
    return token
}

// 給實例添加一個setToken方法，用於登錄後將最新token動態添加到header，同時將token保存在localStorage中
instance.setToken = (token) => {
  instance.defaults.headers['X-Token'] = token
  window.localStorage.setItem('token', token)
}

function refreshToken () {
    // instance是當前request.js中已創建的axios實例
    return instance.post('/refreshtoken').then(res => res.data)
}

// 創建一個axios實例
const instance = axios.create({
  baseURL: '/api',
  timeout: 300000,
  headers: {
    'Content-Type': 'application/json',
    'X-Token': getLocalToken() // headers塞token
  }
})

// 是否正在刷新的標記
let isRefreshing = false
// 重試隊列，每一項將是一個待執行的函數形式
let requests = []

instance.interceptors.response.use(response => {
  const { code } = response.data
  if (code === 1234) {
    const config = response.config
    if (!isRefreshing) {
      isRefreshing = true
      return refreshToken().then(res => {
        const { token } = res.data
        instance.setToken(token)
        config.headers['X-Token'] = token
        config.baseURL = ''
        // 已經刷新了token，將所有隊列中的請求進行重試
        requests.forEach(cb => cb(token))
        requests = []
        return instance(config)
      }).catch(res => {
        console.error('refreshtoken error =>', res)
        window.location.href = '/'
      }).finally(() => {
        isRefreshing = false
      })
    } else {
      // 正在刷新token，將返回一個未執行resolve的promise
      return new Promise((resolve) => {
        // 將resolve放進隊列，用一個函數形式來保存，等token刷新後直接執行
        requests.push((token) => {
          config.baseURL = ''
          config.headers['X-Token'] = token
          resolve(instance(config))
        })
      })
    }
  }
  return response
}, error => {
  return Promise.reject(error)
})

export default instance

希望對大家有幫助。感謝看到最後，感謝點贊^_^。

axios如何利用promise無痛刷新token

需求

需求解析

實現思路

方法一：

方法二：

兩種方法對比

實現

封裝axios基本骨架

instance.interceptors.response.use攔截實現

問題和優化

如何防止多次刷新token

同時發起兩個或以上的請求時，其他接口如何重試

最後完整代碼

公司剛入職了一名 Java 中級開發，短短 4 行代碼居然湊齊了 3 個 bug！我哭了~~

Nginx R31 doc-13-Limiting Access to Proxied HTTP Resources 訪問限流

中外程序員到底有啥區別？

Python數據分析與挖掘實戰（5章）

python包：pandas

C++文件/流

一、什麼是Docker

二、Docker 組件

揹包九講一 01揹包

今天！通義靈碼在北京、成都、杭州三城開講啦

爲什麼說rollup比webpack更適合打包庫

微前端qiankun從搭建到部署的實踐

你可能不知道的mpvue性能優化技巧

不發佈到npm而直接使用github上的庫

axios如何利用promise無痛刷新token（二）

https://yachay.unat.edu.pe/blog/index.php?comment_area=format_blog&comment_component=blog&comment_co

linux以太網驅動總結