第2章 客户端缓存层设计：浏览器缓存机制、Service Worker离线存储、本地存储策略、与服务器同步边界

客户端缓存层是离线架构的第一道防线，也是用户感知性能的关键。本章按照边界定义→分层结构→组件职责→数据流与控制流→选型权衡→风险点→落地步骤→验收标准的架构方案型结构，系统阐述浏览器原生缓存、Service Worker离线存储与本地存储策略的协同方式，并明确客户端与服务器之间的同步边界。

2.1 边界定义

客户端缓存层的管辖范围分为三个核心维度：

• 时间边界：缓存生存周期（TTL）、版本号、会话与持久化策略。
• 空间边界：哪些域、路径、请求方法（GET/POST）可被缓存；存储配额限制。
• 一致性边界：客户端缓存与服务器状态之间的同步策略（强一致、最终一致、脏读容忍度）。

与服务器的同步边界由缓存失效协议和配额检查共同构成。客户端不得擅自延长缓存有效期导致数据陈旧，服务器通过Cache-Control、ETag、Last-Modified以及SW版本消息控制同步时机。

2.2 分层结构

客户端缓存层从请求入口到数据持久化分为四个子层：

2.3 组件职责

• Browser Memory/Disk Cache：被动缓存，由浏览器自动管理，开发者仅能通过HTTP头部控制。适用于图片、CSS/JS静态资源。
• Service Worker：主动拦截网络请求，可编程读写Cache API，实现离线优先或网络优先策略。负责统一管理更新版本、动态调整缓存策略。
• Cache API：为SW提供键值对存储，支持精细的缓存分组（例如v1-static、v1-dynamic）。
• IndexedDB：结构化的NoSQL数据库，适合存储JSON、Blob等复杂离线数据，支持事务与索引查询。
• localStorage/SessionStorage：同步、简单的字符串存储，适用于少量配置或会话标记。

2.4 数据流与控制流

典型请求的数据流路径（以离线优先策略为例）：

1. 用户发起请求 → 浏览器检查L1内存缓存（命中则直接返回）。
2. 未命中则检查L2磁盘HTTP缓存（命中且未过期则返回）。
3. 若L1/L2均未命中，请求被Service Worker的fetch事件拦截。
4. SW首先查询Cache API（L3），命中则直接响应并更新缓存使用时间。
5. 若L3未命中，SW查询IndexedDB（L4），命中则返回并异步发起网络请求以刷新缓存。
6. L4也未命中则发出真实网络请求。响应到达后，SW同时写入Cache API和IndexedDB（按策略），并返回给页面。

控制流信任链路：页面 → SW（受scope限制） → Cache API/IndexedDB（同源安全策略）。SW通过postMessage与页面通信，服务器通过SW版本事件（如install、activate）控制缓存刷新。信任链路必须保证SW脚本由HTTPS提供且未经篡改。

2.5 选型权衡

2.6 风险点

• 缓存污染：SW缓存了过期或损坏的资源，需通过版本清空机制防范。
• 存储配额溢出：IndexedDB/Cache API占用过多空间导致浏览器提示清理，需定期估算并清理。
• 同源限制：所有存储API均受同源策略约束，跨子域共享需要额外机制。
• 安全风险：SW脚本必须通过HTTPS加载；localStorage明文存储敏感数据有泄露风险。
• 缓存一致性问题：离线存储与服务器状态可能长时间不同步，需设计冲突解决策略（如版本号时间戳+服务端校验）。

2.7 落地步骤

1. 资源分类：区分静态资源（JS/CSS/图片）与动态数据（API响应、用户配置）。
2. 配置HTTP缓存头（Cache-Control: max-age、ETag）为L1/L2奠定基础。
3. 注册Service Worker，规划install事件预缓存静态资源，activate清理旧版本缓存。
4. 实现fetch事件处理：离线优先（对关键页面）或网络优先（对实时数据）。
5. 将可离线操作的业务数据（如笔记、消息）存入IndexedDB，采用版本号或Last-Modified标记。
6. 设计同步机制：SW监听到online事件时，将IndexedDB中的待同步记录批量推送到服务器。
7. 监控存储使用量：利用navigator.storage.estimate()设置预警阈值，定期清理过期数据。
8. 安全审查：确保无明文密码存储在localStorage/IndexedDB，SW scope不泄露敏感路由。

2.8 验收标准