JavaScript接口请求本地缓存核心是拦截请求、检查缓存、命中则返回、未命中则请求并存入；推荐localStorage/sessionStorage存小数据，IndexedDB存大文件；需管理缓存时效与一致性。
在 JavaScript 中实现接口请求结果的本地缓存，核心思路是：**拦截请求 → 检查缓存 → 命中则返回缓存 → 未命中则发起真实请求并存入缓存**。关键在于选择合适的缓存策略、存储位置和过期机制。
使用 localStorage 或 sessionStorage 缓存响应数据
适合缓存结构简单、体积较小（一般 ≤5MB）、不需要强实时性的数据，如配置项、用户基础信息、静态列表等。
- 缓存键建议用请求 URL + 请求参数（JSON.stringify 后哈希或直接拼接）生成唯一 key，避免冲突
- 写入时同时保存数据和时间戳，便于后续判断是否过期
- 读取时先检查是否存在、是否超时，再解析返回；否则跳过缓存
示例：
function getCachedData(key) {
const cached = localStorage.getItem(key);
if (!cached) return null;
const { data, timestamp, expires } = JSON.parse(cached);
if (Date.now() > timestamp + expires) {
localStorage.removeItem(key);
return null;
}
return data;
}
<p>function setCachedData(key, data, expiresMs = 5 <em> 60 </em> 1000) {
localStorage.setItem(key, JSON.stringify({
data,
timestamp: Date.now(),
expires: expiresMs
}));
}</p>封装 fetch 或 axios 请求，自动处理缓存逻辑
把缓存判断和更新逻辑内聚到请求函数中，对业务层透明，复用性高。
立即学习“Java免费学习笔记（深入）”；
- 可为每个请求配置是否启用缓存、缓存时长、缓存键生成规则
- GET 请求默认可缓存；POST/PUT 等非幂等方法通常不缓存（除非明确需要）
- 注意响应体类型：JSON 数据可直接缓存；Blob / ArrayBuffer 需转为 base64 或用 indexedDB
简单封装示例（基于 fetch）：
async function cachedFetch(url, options = {}) {
if (options.method && !['GET', 'HEAD'].includes(options.method.toUpperCase())) {
return fetch(url, options);
}
<p>const cacheKey = <code>cache_${url}${options.cacheKey || ''}</code>;
const cached = getCachedData(cacheKey);
if (cached !== null) return Promise.resolve({ json: () => Promise.resolve(cached) });</p><p>const res = await fetch(url, options);
const data = await res.clone().json();
setCachedData(cacheKey, data, options.cacheTTL || 300000); // 默认 5 分钟
return res;
}</p>对高频/大体积数据考虑使用 IndexedDB
当需要缓存图片、文件、大量列表或需支持查询、事务、较大容量（数百 MB）时，localStorage 不适用，IndexedDB 是更优选择。
- 用
idb库（轻量、Promise 化）简化操作，避免原生 IDB 的复杂回调 - 按接口维度建 store，keyPath 设为 url + hash 参数，方便精确读写
- 支持缓存清理策略，如 LRU（最近最少使用）或按时间批量删除
注意缓存一致性与失效时机
缓存不是“设了就完事”，必须主动管理生命周期，否则容易出现脏数据。
- 在相关数据变更的请求成功后（如 POST 新增、PUT 修改、DELETE 删除），同步清除对应缓存 key
- 对全局变动（如用户登出、版本升级），可清空整个缓存域
- 服务端可通过响应头（如
Cache-Control、ETag）配合协商缓存，但浏览器原生缓存不适用于跨域或自定义鉴权场景，JS 层仍需独立控制
