通过拦截 fetch 请求并维护一个基于 url 的 promise 缓存对象，可以实现接口数据的复用。具体做法是在发起请求前检查缓存中是否存在该 url 对应的 promise，若存在则直接返回该 promise 以复用结果；若不存在则创建新的请求 promise 并存入缓存，待请求完成后自动清理或保留（视策略而定），从而避免重复的网络开销。
如何封装带缓存逻辑的 fetch 函数
实现的核心在于创建一个全局的 cache Map 对象，并在自定义的 cachedFetch 函数中进行判断。当调用该函数时，首先检查 cache 中是否已存在当前请求 URL 的键值对。如果存在，直接返回缓存中的 Promise 实例，这样多个并发调用会共享同一个网络请求和响应数据。如果不存在，则执行实际的 fetch 操作，将生成的 Promise 存入 cache，并在请求完成（无论成功或失败）后从 cache 中删除该键，以确保后续新请求能获取最新数据。这种“请求-缓存-失效”的模式既实现了复用，又避免了数据永久陈旧的问题。
const cache = new Map();
async function cachedFetch(url, options = {}) {
if (cache.has(url)) {
console.log('Cache hit:', url);
return cache.get(url);
}
console.log('Fetching:', url);
const promise = fetch(url, options)
.then(response => {
if (!response.ok) throw new Error('Network error');
return response.json();
})
.finally(() => {
cache.delete(url);
});
cache.set(url, promise);
return promise;
}
// 测试用例
const data1 = await cachedFetch('/api/data');
const data2 = await cachedFetch('/api/data');
console.log(data1 === data2); // true, 复用了同一个 Promise 结果
上述代码定义了一个简单的缓存机制。运行结果显示，第二次调用 cachedFetch 时，由于 cache 中已存在该 URL 的 Promise，因此直接返回了之前的结果，且 data1 和 data2 引用的是同一个对象。这证明了在 Promise 解析完成前，多次调用确实复用了同一个网络请求。
如何处理不同请求方法的缓存策略
在实际应用中，GET 请求通常适合缓存，而 POST、PUT 等写操作不应被缓存，因为它们可能改变服务器状态。因此，需要在 cachedFetch 中增加对请求方法的判断。只有当请求方法为 GET 时才启用缓存逻辑，对于其他方法则直接执行原始 fetch 而不经过缓存。此外，还可以根据 URL 参数或请求体生成唯一的缓存键，以支持更复杂的缓存场景，例如针对相同资源但不同查询条件的 GET 请求分别缓存。
你是 TypeScript 项目架构专家，专注于脚手架搭建生产就绪的 Node.js 和前端应用。生成包含现代工具链（pnpm、Vite、Next.js）、类型
async function smartCachedFetch(url, options = {}) {
const method = (options.method || 'GET').toUpperCase();
// 仅对 GET 请求启用缓存
if (method !== 'GET') {
console.log('Non-GET request, bypassing cache:', url);
return fetch(url, options).then(res => res.json());
}
if (cache.has(url)) {
console.log('Cache hit for GET:', url);
return cache.get(url);
}
console.log('Fetching GET:', url);
const promise = fetch(url, options)
.then(response => {
if (!response.ok) throw new Error('Network error');
return response.json();
})
.finally(() => {
cache.delete(url);
});
cache.set(url, promise);
return promise;
}
// 测试：POST 请求不缓存
await smartCachedFetch('/api/data', { method: 'POST' });
await smartCachedFetch('/api/data', { method: 'POST' });
// 两次都会发起实际网络请求
修改后的 smartCachedFetch 函数增加了对 HTTP 方法的检查。当使用 POST 方法时，函数跳过缓存逻辑，直接发起网络请求。这确保了写操作不会被错误地复用，同时保持了 GET 请求的缓存效率。测试表明，连续两次 POST 请求都会触发控制台输出“Fetching”，证实了缓存被正确绕过。
基于程序中某个输入、条件或结果的具体问题
在上述实现中，如果两个不同的 URL 指向相同的资源，或者用户希望手动清除特定缓存，当前的简单 Map 结构可能不够灵活。例如，若希望缓存所有以 /api/ 开头的请求，或者在特定条件下（如页面刷新）清除所有缓存，需要扩展缓存管理逻辑。可以通过添加 clearCache() 方法来重置整个 Map，或者引入更复杂的键生成策略，如将 URL 和请求参数哈希化作为缓存键，以支持更细粒度的控制。
大量免费API接口：立即使用
涵盖生活服务API、金融科技API、企业工商API、等相关的API接口服务。免费API接口可安全、合规地连接上下游，为数据API应用能力赋能！
