源码重复请求拦截逻辑？

访客源码剖析 2026-06-08 00:28:12 2

前端源码中的幂等性逻辑深度解析

目录导读

为什么需要拦截重复请求？ – 从用户体验到后端压力的现实痛点
重复请求的常见场景 – 用户误操作、网络重试、接口回调
源码级实现：四种主流拦截方案
- 基于请求URL+参数的哈希缓存
- 基于请求时间戳的节流防抖
- 基于Promise状态的全局锁机制
- 基于Axios拦截器的统一封装
源码示例与对比 – 从简单到完善的代码实现
常见问题与解答（Q&A） – 命中率、内存泄漏、并发场景
SEO优化建议 – 元描述、标签、长尾关键词布局
– 选择最适合你业务场景的拦截策略

为什么需要拦截重复请求？

在Web开发中，重复请求 是指用户或系统在短时间内对同一接口发起多次完全相同的请求，根据多家互联网公司的故障报告，重复请求导致的数据库写入错误、缓存击穿、分布式锁争用等问题，占线上事故的15%-20%。

核心痛点：

用户体验：用户点击提交按钮后，页面无响应，再次点击导致多个请求同时发出，后端返回多条数据或执行多次操作（如重复下单、重复扣款）。
后端压力：高并发下，重复请求会耗尽服务器连接池,导致正常请求被阻塞。
数据一致性：重复的写操作可能导致数据库记录重复、库存扣减多次、支付回调重复处理。

重复请求的常见场景

场景	触发原因	案例
用户误操作	用户快速点击“提交”按钮	支付页面点击2次下单按钮
网络重试机制	前端axios/fetch自动重试	弱网环境下接口超时后自动重发
组件生命周期	页面组件卸载又挂载	React useEffect未清除定时器导致的重复请求
路由重复切换	用户快速切换同一页面	Tab页快速切换触发相同数据加载
轮询与推送	短时间收到多条同类型消息	WebSocket推送后前端又发起手动请求

源码级实现：四种主流拦截方案

基于请求URL+参数的哈希缓存

核心逻辑：用一个对象（Map）存储已发起的请求，以${method}:${url}:${JSON.stringify(params)}为key，存储一个Promise，当相同请求再次到来时,直接返回已有Promise。

const pendingRequests = new Map();
function requestWithCache(config) {
  const key = `${config.method}:${config.url}:${JSON.stringify(config.params || config.data)}`;
  if (pendingRequests.has(key)) {
    return pendingRequests.get(key); // 重复请求，返回同一Promise
  }
  const promise = axios(config).finally(() => {
    pendingRequests.delete(key); // 请求完成后清除缓存
  });
  pendingRequests.set(key, promise);
  return promise;
}

优点：简单高效，避免重复发起HTTP请求。
缺点：若请求参数相同但响应体期望不同（如携带不同token）,会导致错误。

基于请求时间戳的节流防抖（按钮级别）

适用于表单提交场景,限制用户多次点击。

// 防抖：最后一次点击后延迟执行
function debounceSubmit(callback, delay = 300) {
  let timer = null;
  return function (...args) {
    clearTimeout(timer);
    timer = setTimeout(() => callback.apply(this, args), delay);
  };
}
// 节流：固定时间间隔内只执行一次
function throttleSubmit(callback, interval = 1000) {
  let lastTime = 0;
  return function (...args) {
    const now = Date.now();
    if (now - lastTime >= interval) {
      lastTime = now;
      callback.apply(this, args);
    }
  };
}

优点：对用户点击动作直接拦截，无需关心接口URL。
缺点：无法拦截由代码发起的重复调用（如setState后的自动重发）。

基于Promise状态的全局锁机制

核心：用一个Map记录当前正在请求的接口，请求完成后释放锁,适用于所有前端框架。

const requestLock = new Map();
function requestWithLock(config) {
  const key = config.url; // 也可加上方法
  if (requestLock.get(key)) {
    return Promise.reject(new Error('请求正在处理中，请勿重复提交'));
  }
  requestLock.set(key, true);
  return axios(config)
    .then(response => {
      requestLock.delete(key);
      return response;
    })
    .catch(error => {
      requestLock.delete(key);
      throw error;
    });
}

优点：语义清晰，确保同一时间只有一个请求正在进行。
缺点：若用户不等待完成直接刷新页面，锁可能一直存在,需配合页面卸载时清除。

基于Axios拦截器的统一封装（推荐）

最实用的生产级方案：在全局Axios实例中添加请求/响应拦截器,统一处理重复请求。

// interceptors.js
const pendingRequests = new Map();
axios.interceptors.request.use(config => {
  const key = `${config.method}:${config.url}`;
  if (pendingRequests.has(key)) {
    config.cancelToken = new axios.CancelToken(cancel => {
      cancel('重复请求已被拦截');
    });
  } else {
    pendingRequests.set(key, true);
  }
  return config;
});
axios.interceptors.response.use(
  response => {
    const key = `${response.config.method}:${response.config.url}`;
    pendingRequests.delete(key);
    return response;
  },
  error => {
    if (!axios.isCancel(error)) {
      const key = `${error.config?.method}:${error.config?.url}`;
      pendingRequests.delete(key);
    }
    return Promise.reject(error);
  }
);

优点：全局生效，无需修改每个组件；支持取消请求（CancelToken）。
缺点：需要合理设计key的粒度,避免误拦截。