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 天） - 敏感操作（如登出、切换账号）后，清空全部用户相关缓存
不复杂但容易忽略。核心是把缓存当成“有生命周期的副产物”，而不是“万能加速开关”。
