前端二级数据缓存机制以Web Storage和IndexedDB分层承载，构建“一级内存+二级持久”缓存体系，职责是弱网/离线可用、降请求、保状态，需满足自动回填、智能失效、优雅降级三大刚性条件。
前端二级数据缓存机制，核心是把“网络请求”和“本地读取”解耦，让非关键路径的数据不依赖实时接口，同时保障一致性与可用性。三驾马车不是并列使用，而是按数据特征分层承载：Web Storage（localStorage/sessionStorage）做轻量锚点，IndexedDB做结构化主干，二者共同构成可落地的二级缓存——即“一级内存缓存 + 二级持久缓存”，其中“二级”特指落盘、跨会话、可恢复的本地存储层。
明确二级缓存的职责边界
二级缓存不替代服务端，也不追求强一致，目标是：弱网/离线时可用、高频读场景降请求、关键状态不丢失。它必须满足三个刚性条件：能自动回填（从接口获取后写入）、能智能失效（按时间或业务事件清理）、能优雅降级（写失败时暂存内存或丢弃）。
- localStorage 存用户级静态配置（主题、语言、默认筛选项），带版本号前缀（如 v2_user_prefs），便于灰度迁移
- sessionStorage 存单页会话态（表单草稿、临时搜索参数、导航栈快照），关闭即清，不参与跨标签同步
- IndexedDB 存业务实体数据（消息列表、文章正文、订单历史），每个 domain 建独立 objectStore，字段加索引（如 by_status_and_updatedAt）
设计统一缓存访问层，屏蔽底层差异
避免在业务代码里直接调用 getItem() 或 idb.open()。封装一个 CacheManager，对外提供 get/set/delete/clear 方法，内部根据 key 类型自动路由：
- 以 cfg: 开头的 key → 走 localStorage（自动 JSON 序列化/反序列化）
- 以 tmp: 开头的 key → 走 sessionStorage
- 以 data: 开头的 key → 走 IndexedDB（自动映射到对应 objectStore，支持复合 key 查询）
- 所有写操作都附带 TTL 时间戳（毫秒），读取时自动校验是否过期
实现可靠的数据同步与失效策略
二级缓存最大的风险是脏数据。不能只靠“过期时间”，要结合业务语义主动触发刷新：
立即学习“前端免费学习笔记（深入）”；
- 关键接口响应头带 Cache-Control: max-age=300 → 缓存 5 分钟，到期后下次读取自动触发后台刷新（stale-while-revalidate）
- 用户执行“下拉刷新”或“手动同步”动作 → 清空对应 objectStore 并重新 fetch 全量数据
- 监听 storage 事件，当其他标签页更新了 localStorage 配置 → 当前页同步更新 UI（如主题切换）
- IndexedDB 写失败（如磁盘满、版本冲突）→ 自动降级为内存 Map 缓存，并标记 “pending_sync:true”，网络恢复后重试
规避常见陷阱，保障稳定性
三驾马车协同的前提是不出错。几个必须处理的细节：
- Safari 无痕模式下 localStorage 可能直接抛错 → 所有 setItem 操作包 try-catch，降级写入 WeakMap
- IndexedDB 版本升级需显式 abort 旧事务 → 升级时先 close 所有已有连接，再 open 新版本库
- localStorage 单条超 2MB 或总容量逼近 5MB → 触发 LRU 清理，优先剔除带 _temp 后缀的旧数据
- 避免在 React/Vue 的 effect 中频繁读写 localStorage → 封装 useCachedState Hook，内部节流 + 监听 storage 变更
