IndexedDB缓存API响应需明确新鲜度策略：5分钟内读缓存，超时则stale-while-revalidate；按URL+参数生成cacheKey索引；降级回退网络；设expiresAt并定期清理。

用 IndexedDB 缓存 API 响应，能显著加快页面二次加载速度，尤其适合数据变动不频繁的接口（如用户资料、配置项、静态列表）。关键不是“存”，而是“怎么判断用缓存还是发请求”。

缓存策略要明确：什么时候读缓存，什么时候更新

不能简单“有缓存就读”，否则容易展示过期数据。常见做法是结合时间戳或版本号做新鲜度控制：

• 写入缓存时，同时存一个 lastUpdated 时间戳（Date.now()）
• 读取前检查：若当前时间 - lastUpdated
• 对强一致性要求高的接口（如余额、订单状态），可跳过缓存，或加个强制刷新参数（如 ?_t=123456789）绕过缓存逻辑

用 objectStore 按 URL + 参数建索引，避免重复存储

同一个接口带不同 query 或 body，应视为不同条目。建议把请求唯一标识（如序列化后的 URL 和 JSON body）作为 keyPath：

• 创建 objectStore 时设 keyPath: 'cacheKey'
• 生成 cacheKey 示例：`${url}|${JSON.stringify(params)}`（注意过滤敏感字段）
• 查询时直接 store.get(cacheKey)，比遍历所有记录快得多

错误降级要自然：缓存不可用时无缝回退到网络

IndexedDB 可能被禁用、配额超限，或事务失败。不能让整个请求卡住：

• 打开数据库失败时，直接走 fetch，不报错也不阻塞
• 读缓存失败（如数据损坏），捕获异常后继续发请求，同时清理该条缓存
• 写缓存失败（如超出 quota），记录 warning 日志，但不影响主流程响应

清理机制不能少：避免无限膨胀和脏数据堆积

长期运行的单页应用，缓存会越积越多。需主动管理：

• 为每条缓存加 expiresAt 字段（如 Date.now() + 24 * 60 * 60 * 1000），读取前先校验是否过期
• 定期在空闲时（如页面隐藏、定时器）调用 clear() 或按条件删除（如 lastUpdated 超过 7 天）
• 敏感操作（如登出、切换账号）后，清空全部用户相关缓存

不复杂但容易忽略。核心是把缓存当成“有生命周期的副产物”，而不是“万能加速开关”。

大量免费API接口：立即使用
涵盖生活服务API、金融科技API、企业工商API、等相关的API接口服务。免费API接口可安全、合规地连接上下游，为数据API应用能力赋能！