前后端分离使用token进行登录验证时，由于token存在过期时间，每次token过期都需要用户重新登录的话，用户体验很不友好。假如token能跟session一样，如果用户持续在进行操作，就自动延长有效时间，就可以解决问题。但是，token一旦签发，服务器就没法再延长token的有效期，目前用的比较多的应该是使用双token实现token续签，当token过期时，签发新的token给前端，前端携带新的token请求后端接口。

具体思路：在签发token时生成两个token，accessToken和refreshToken，前端每次请求时携带accessToken，后端发现accessToken过期时，返回token已过期的结果。前端根据后端状态码判断token是否已经过期，如果过期则携带refreshToken请求刷新token的接口，如果refreshToken没有过期，则后端重新生成accessToken和refreshToken返回给前端；如果refreshToken也过期了，则返回结果要求前端重新登录。

后端实现

accessToken设置过期时间为30分钟，refreshToken设置过期时间为60分钟，这样的话accessToken过期后的30分钟内用户有操作，仍可以使用refreshToken请求刷新token。

创建accessToken

创建refreshToken

JWT解析token，token过期则返回-1，其他解析错误则返回-2，解析成功返回1。

LoginController验证账号密码成功后，创建accessToken和refreshToken返回前端，将accessToken和refreshToken保存在redis中。为避免用户退出登录或更换设备登录后，旧的accessToken和refreshToken还没有过期，仍然能生效，在redis中使用user的id为键保存的accessToken和refreshToken，每次登录后都会将原来的进行覆盖，这样只需要在拦截器中将token与reids中进行比对，如果比对不一致，则不放行。

登录生成accessToken和refreshToken

LoginInterceptor验证accessToken，如果返回-1，则表示accessToken过期，提示用户需要刷新token。为了避免用户在新设备登录，旧设备的accessToken仍然有效，每次校验完accessToken成功，都还要在redis中查找是否存在以id为key的记录，并且将redis中取出的redisToken和accessToken对比是否一致，如果没有或不一致，则表示accessToken已经被redis作废，仍不能放行，返回客户端信息为该账号已在其他设备登录，请重新登录。

代码截不全，主要逻辑都在

refreshToken接口。刷新token的接口/api/refresh用于前端调用。首先刷新token的接口要在Interceptor中放行，避免refreshToken过期后，返回结果仍然是需要刷新token。只有refreshToken解析成功并且与redis中的refreshToken一致时，才会重新签发accessToken和refreshToken。

刷新token的接口

前端实现

前端实现靠axios的请求拦截器和响应拦截器，请求拦截器配置每次请求携带token，主要的难题在于多请求下响应拦截器的处理。

具体思路：设置一个刷新token的状态isRefreshAvailable并设置为true，同时发出多个请求时，token过期都会由后端返回需要刷新token的信息，那么，当第一个响应回来进入刷新token程序后，将isRefreshAvailable设置为false，其他请求都不能再发起刷新token请求，使用promise将剩下的请求放入一个缓存数组，当刷新token结束后再遍历数组将缓存的请求逐个发出。

由于前端知识不足，网上查了不少办法，主要出现两个问题，问题的分析不知道是否正确，最后用了setTimeout延迟3秒再将isRefreshAvailable设置为true并且重新发送缓存的请求，没发现再出现以下两个问题。如果有好的解决办法，请不吝赐教，万分感激：

问题1、刷新token接口多次被调用。调用了7个请求系统时间接口的请求，按照网上的办法，调用刷新token接口得到新的accessToken和refreshToken后就将isRefreshAvailable设置为true，但有的原始请求响应晚于刷新token的请求响应，造成多次调用刷新token接口，而后端即便token解析成功也会从redis中进行比对，造成重发的请求携带的accessToken与redis中不一致，比对失败返回重新登录页面。解决问题的关键在于何时改变isRefreshAvailable的状态。

问题2、请求丢失的问题。原始请求因为返回结果较晚，当刷新完token开始遍历缓存数组的时候，有的原始请求结果才返回，这样即便进了数组，也没有能够重新发送。

发送了7个系统时间请求，刷新token后只重发了2个

前端代码：

accessToken和refreshToken存放在sessionStorage中，获取accessToken和refreshToken的以及清空sessionStorage到登录页面的函数：

function getAccessToken () {  return window.sessionStorage.getItem('token')}function getRefreshToken () {  return window.sessionStorage.getItem('refreshToken')}function toLogin () {  setTimeout(() => {    window.sessionStorage.clear()    isRefreshAvailable = true    requestAttr = []    window.location.href = '/login'  }, 3000)}

刷新token的函数：获得刷新后的accessToken和refreshToken后，保存到sessionStorage中，得到新的token后这里先不设置isRefreshAvailable为ture。

刷新token函数

async function refreshToken () {  try {    var result = await http({      url: '/test/refresh',      method: 'post',      headers: {        Refresh: getRefreshToken()      }    })  } catch (e) {    messageOnce.error({ message: '自动获取授权失败! 3秒后自动跳转至登录界面' })    toLogin()  }  if (result.status === 200) {    window.sessionStorage.setItem('token', result.accessToken)    window.sessionStorage.setItem('refreshToken', result.refreshToken)  }}

请求拦截器：每次请求都在请求头中设置Authorization字段携带token，这里使用了element ui的Loading加载组件，为了确保所有的ajax请求响应后再关闭Loading，使用了loadCount进行计数，每发起一个请求，loadCount加1。

请求拦截器

http.interceptors.request.use(  config => {    var token = getAccessToken()    token && (config.headers.Authorization = token)    loadCount++    loadingInstance = Loading.service({      text: '正在加载...'    })    return config  },  error => {    loadingInstance.close()    messageOnce.warning({ message: '请求超时' })    return Promise.reject(error)  })// 是否可以刷新标识let isRefreshAvailable = true// 缓存请求的数组let requestAttr = []

响应拦截器：当后端响应token相关错误的状态码时，10001代表没有token，10002代表token解析失败，10003代表refreshToken过期，清空sessionStorage并自动跳转至登录界面。这里每有一个请求得到响应，就将loadCount减1，当loadCount为0，且isRefreshAvailable为true时，关闭Loading组件。当后端响应accessToken过期的10000时，根据isRefreshAvailable判断是否正在刷新token，isRefreshAvailable为true，表示可以刷新token，调用刷新token的refreshToken函数，并将isRefreshAvailable设置为false，其他响应不能再调用refreshToken函数。为了避免前述的token多次刷新和请求丢失的两个问题，刷新完token，3秒后再将缓存数组中的请求进行重发，并且将isRefreshAvailable设置为true。

响应拦截器

如果其他token过期的响应回来时正在刷新token，则使用promise将请求存入缓存数组requestAttr，如果不是token相关的错误状态码，则打印错误结果，如果状态码为成功200，则将响应数据返回。

响应拦截器

http.interceptors.response.use(  response => {    loadCount--    if (loadCount === 0 && isRefreshAvailable === true) {      loadingInstance.close()    }    if (response.data.status === 10001 || response.data.status === 10002 || response.data.status === 10003) {      messageOnce.error({ message: response.data.message + '! 3秒后自动跳转至登录界面' })      toLogin()    } else if (response.data.status === 10000) {      if (isRefreshAvailable) {        isRefreshAvailable = false        refreshToken()        // 拿到新accessToken后，等待2-3秒，确保其他请求响应都回来后再重新发送请求        // 防止重发数组请求后才有请求返回，丢失该部分请求        setTimeout(() => {          console.log('开始重新发起请求')          requestAttr.forEach((cb) => cb(getAccessToken()))          requestAttr = []          isRefreshAvailable = true          response.config.headers.Authorization = 'Bearer' + getAccessToken()          return http(response.config)        }, 3000)      } else {        return new Promise(resolve => {          requestAttr.push((token) => {            console.log('缓存数组的数量：', requestAttr.length)            response.config.headers.Authorization = 'Bearer' + token            resolve(http(response.config))          })        })      }    } else if (response.data.status !== 200) {      messageOnce.warning({ message: response.data.message })    } else {      return response.data    }  },  error => {    // 对响应错误做点什么    loadCount = 0    loadingInstance.close()    messageOnce.error({ message: '与服务器连接发生错误' })    return Promise.resolve(error)  })

最终效果，发出7个请求系统时间的请求，得到7个需要刷新token的响应，只调用了一次refresh接口，又重新发送了7个请求系统时间的请求。

正确的结果

PS：这个代码块对手机支持不太友好啊，预览了下，过宽的代码块没有出现滚动条啊。