在ofetch中使用拦截器实现请求队列与Token刷新机制

背景介绍

在现代Web应用中，处理身份验证和Token刷新是一个常见需求。当使用ofetch这样的HTTP客户端时，我们需要优雅地处理401未授权错误，并在Token过期时自动刷新Token，同时确保并发请求能够正确排队等待刷新完成。

核心问题分析

当多个API请求同时发生且Token过期时，会出现以下问题：

1. 第一个请求检测到401错误，触发Token刷新流程
2. 其他并发请求也会检测到401错误，各自触发Token刷新
3. 这会导致多次刷新Token请求，可能造成Token失效或服务器压力

解决方案实现

基本拦截器结构

首先创建一个基本的ofetch实例，设置基础URL和拦截器：

import { ofetch } from "ofetch"

const apiFetcher = ofetch.create({
  baseURL: import.meta.env.VITE_API_BASE_URL + '/api',
  timeout: 30000,
  retry: false,
  credentials: 'include'
})

请求队列管理

为了实现请求排队，我们需要三个关键变量：

let refreshingToken = false  // 标记是否正在刷新Token
let requestsQueue = []       // 等待队列

// 处理队列中的请求
const processQueue = (error, token = null) => {
  requestsQueue.forEach((prom) => {
    if (error) {
      prom.reject(error)
    } else {
      prom.resolve(token)
    }
  })
  requestsQueue = []  // 清空队列
}

响应拦截器实现

在响应拦截器中处理401错误和Token刷新逻辑：

apiFetcher.onResponse(async (ctx) => {
  if (ctx.response.status === 401) {
    // 如果已经在刷新Token，将请求加入队列
    if (refreshingToken) {
      return new Promise((resolve, reject) => {
        requestsQueue.push({ resolve, reject })
      }).then((resp) => {
        if (resp) {
          return ofetch(ctx.request, ctx.options)
        }
      })
    }
    
    // 标记开始刷新Token
    refreshingToken = true
    
    try {
      // 发送刷新Token请求
      const retry = new Promise((resolve, reject) => {
        ofetch.raw('/auth/Refresh-Token', {
          baseURL: import.meta.env.VITE_API_BASE_URL + '/api',
          method: 'POST',
          credentials: 'include'
        }).then((resp) => {
          // 处理成功，通知队列继续执行
          processQueue(null, resp._data)
          resolve()
        }).catch(err => {
          // 处理失败，通知队列并登出
          processQueue(err, null)
          const authStore = useAuthStore()
          authStore.signOut()
          reject()
        }).finally(() => {
          refreshingToken = false
        })
      })
      
      await retry
    } catch (error) {
      // 错误处理
    }
  }
})

请求重试封装

为了简化使用，可以创建一个封装函数处理初始请求和重试逻辑：

import type { FetchRequest, FetchOptions, FetchResponse } from "ofetch"

const apiFetchRaw = async <T = any>(request: FetchRequest, options?: FetchOptions) => {
  try {
    const response = await apiFetcher.raw(request, options)
    return response as FetchResponse<T>
  } catch (error: any) {
    if (error.response?.status === 401) {
      // Token刷新后重试原始请求
      const response = await apiFetcher.raw(request, options)
      return response as FetchResponse<T>
    }
    return error.response as FetchResponse<T>
  }
}

方案优势

1. 避免重复刷新：使用refreshingToken标记确保只有一个刷新请求
2. 请求排队：后续请求会加入队列等待刷新完成
3. 自动重试：Token刷新后自动重试原始请求
4. 错误处理：刷新失败时自动登出并清理队列

实际应用建议

1. 根据实际项目调整Token存储方式（localStorage/cookie等）
2. 考虑添加额外的错误处理和日志记录
3. 在SSR环境中需要特别注意Token的存储和传递
4. 可以扩展支持多种认证方式

这种实现方式确保了在Token过期时的良好用户体验，同时保持了代码的整洁和可维护性。