在 javascript 中实现 fetch api 的请求结果节流，核心思路是维护一个请求队列或状态标志位，确保在指定的时间窗口内，针对同一资源只发起一次网络请求。具体做法是在发起请求前检查是否已有未完成的请求，若有则复用该 promise 对象并返回其结果；若无且处于冷却期，则直接丢弃新请求或等待冷却结束。这样做能有效避免短时间内重复请求导致的服务器压力过大和前端数据更新混乱。
如何拦截并合并重复的 Fetch 请求
通过封装一个带有缓存机制的 fetch 函数，可以自动处理重复请求。当多个组件同时调用该函数时，它们会共享同一个 Promise 实例，从而保证只有一个真实的 HTTP 请求发出，其他调用者则在原地等待结果。
const requestCache = new Map();
function throttledFetch(url, options = {}) {
// 如果当前有正在进行的请求，直接返回已有的 Promise
if (requestCache.has(url)) {
return requestCache.get(url);
}
// 创建新的请求并缓存其 Promise
const promise = fetch(url, options)
.then(response => {
if (!response.ok) {
throw new Error('Network response was not ok');
}
return response.json();
})
.finally(() => {
// 请求结束后移除缓存，允许下一次请求
requestCache.delete(url);
});
requestCache.set(url, promise);
return promise;
}
// 使用示例
throttledFetch('/api/data')
.then(data => console.log('Data received:', data));
上述代码定义了一个 throttledFetch 函数，它使用 Map 对象来存储 URL 对应的 Promise。当首次调用时，它会执行实际的 fetch 操作并将生成的 Promise 存入缓存。后续相同的 URL 调用将直接获取缓存中的 Promise。利用 .finally() 方法确保无论请求成功还是失败，都会清理缓存，防止内存泄漏并允许后续的新请求正常发起。
立即学习“Java免费学习笔记（深入）”；
你是 TypeScript 项目架构专家，专注于脚手架搭建生产就绪的 Node.js 和前端应用。生成包含现代工具链（pnpm、Vite、Next.js）、类型
如何实现基于时间的请求去重与延迟执行
除了简单的缓存复用，有时需要更精细的控制，例如在用户快速输入时，只在最后一次输入后等待一段时间再发送请求。这可以通过结合定时器（Timer）和状态标记来实现，确保在时间窗口内的多次触发只导致一次最终的请求执行。
let timerId = null;
const DEBOUNCE_DELAY = 500; // 500毫秒
function debouncedFetchWithDelay(url, options = {}) {
// 清除之前的定时器
if (timerId) {
clearTimeout(timerId);
}
// 设置新的定时器
timerId = setTimeout(() => {
// 在定时器回调中执行实际的 fetch
fetch(url, options)
.then(res => res.json())
.then(data => {
console.log('Delayed request result:', data);
// 处理数据...
})
.catch(err => console.error('Fetch error:', err))
.finally(() => {
timerId = null; // 重置状态
});
}, DEBOUNCE_DELAY);
}
// 模拟用户快速点击或输入
// debouncedFetchWithDelay('/api/search?q=test');
这段代码展示了一种防抖（Debounce）策略，常用于搜索框等场景。每次调用 debouncedFetchWithDelay 都会先清除之前设置的定时器，然后重新设置一个新的定时器。只有当用户在设定的时间间隔（如 500ms）内不再触发该函数时，定时器才会执行内部的 fetch 逻辑。这种方式不仅实现了节流效果，还确保了只有在用户操作静止后才进行网络交互，极大减少了无效请求。
如何处理并发请求中的竞态条件问题
在使用节流或防抖策略时，可能会遇到旧请求比新请求晚完成的情况，导致界面上显示的是过时的数据。为了解决这个问题，可以在每个请求中附加一个唯一的标识符（如时间戳或递增 ID），并在接收到响应时验证该标识符是否为最新，如果不是则忽略该结果。
let latestRequestId = 0;
function raceConditionSafeFetch(url, options = {}) {
const currentRequestId = ++latestRequestId;
return fetch(url, options)
.then(response => response.json())
.then(data => {
// 关键步骤：检查当前请求是否是最新的
if (currentRequestId === latestRequestId) {
console.log('Updating UI with latest data:', data);
// 更新界面...
} else {
console.log('Ignoring stale response for request', currentRequestId);
}
})
.catch(err => {
if (currentRequestId === latestRequestId) {
console.error('Error in latest request:', err);
}
});
}
// 即使被节流或防抖，内部逻辑也可用于更复杂的并发控制场景
虽然前面的例子主要关注减少请求数量，但在实际应用中，结合竞态条件检查能进一步提升用户体验。latestRequestId 变量作为一个全局计数器，每次发起请求时自增。当异步请求返回时，比较当前的 currentRequestId 与全局最新的 latestRequestId。如果两者不一致，说明在此期间有新的请求发出，当前的响应即为“过时”数据，应予以丢弃。这种模式常与防抖或节流结合使用，确保最终呈现给用户的永远是最新一次操作的预期结果。
