前端缓存策略与离线体验

缓存可以减少重复下载、降低服务器压力，也能在网络不稳定时改善体验。缓存同时会带来数据过期和版本不一致问题，因此必须为不同资源设计更新规则。

一、按资源性质选择缓存方式

带内容哈希的静态资源可以长时间缓存，因为文件内容变化时文件名也会变化。入口文档通常需要及时重新验证，避免用户一直拿到旧版本入口。

带版本标识的静态资源 -> 长期复用
入口文档和动态数据 -> 按业务要求重新验证

用户信息、权限结果和实时库存不适合套用静态资源的长缓存策略。

二、区分缓存层

浏览器 HTTP 缓存适合复用请求响应；内存缓存适合当前会话中的快速访问；IndexedDB 适合较大量、结构化且需要跨会话保存的数据；本地存储适合少量简单设置。

不同存储的容量、同步方式和事务能力不同。不要把大型列表或敏感数据无差别放进本地存储。

三、离线缓存先定义用户预期

离线体验可以缓存应用外壳和近期访问的数据，但必须区分缓存内容和最新内容。页面可以显示上次更新时间，让用户判断信息是否仍可用。

Service Worker 可以拦截资源请求并执行缓存策略。安装、更新和激活流程要可预测，更新中的旧页面也应保持可用，避免缓存切换后出现资源版本混杂。

四、选择缓存更新策略

缓存优先适合离线也要快速展示的内容；网络优先适合时效性较高的数据；先返回缓存并在后台刷新适合希望兼顾速度和新鲜度的列表。

策略应按请求类型设置，而不是对所有请求使用同一种模式。写操作一般需要明确服务器确认，不能因为本地缓存成功就误报提交成功。

五、设计失效与版本迁移

缓存键应包含会影响结果的查询条件、用户范围或数据版本。退出登录时要清理该用户的私有缓存；应用升级时应迁移兼容数据或删除旧结构。

const cacheKey = userId + ":" + categoryId + ":" + page;

不要把访问凭据直接拼入可被其他脚本读取的缓存标识或日志。

六、处理存储失败

浏览器可能清理站点数据，存储空间也可能不足。因此缓存应被视为可重建的数据副本，关键业务结果仍以服务器确认为准。写入失败时保留在线流程，并记录必要的诊断信息。

七、理解新鲜度验证与失效

缓存命中不一定意味着浏览器每次都直接使用旧响应。资源可以携带新鲜度策略，过期后向服务器验证是否变化；内容未变化时复用本地副本，内容变化时下载新版本。应用应根据内容时效选择验证周期，静态带版本资源和用户实时数据不能套用同一套规则。

缓存键必须包含会影响响应的条件。语言、用户身份、查询筛选和内容编码若改变结果，却没有进入缓存区分维度，就可能出现错语言、旧用户数据或过滤条件串用。个性化响应应谨慎共享缓存，退出账号时清理对应私有数据。

八、为缓存数据标注来源和时间

仓库可以记录数据来源、更新时间和版本，让页面区分“刚从服务器取得”“来自本地缓存”和“离线旧数据”。用户做重要决策时，应知道内容是否过期。缓存仅作为副本，不能替代服务器对写入结果的最终确认。

更新策略还应处理并发请求。同一数据被多个页面同时读取时可复用进行中的请求；写入后应使相关读取缓存失效，避免保存成功后仍显示旧数据。

九、离线写入与缓存读取分开设计

离线读取可以返回上次内容；离线写入则需要排队、幂等、冲突解决和同步状态。两个能力不能只靠一个“离线模式”布尔值混在一起。网络恢复后先展示正在同步，再以服务端确认结果替换乐观状态。

十、建立缓存清理和升级流程

应用升级时，旧缓存可能引用已删除资源。清理前要确认仍打开的旧页面是否依赖它们，并提供失败回退。用户存储配额不足时，优先淘汰可重建的旧缓存，保留用户明确保存的草稿。

实施中的取舍与复核

缓存应按数据语义分层，而不是把所有响应都设置成相同有效期。静态版本化资源适合长时间缓存，用户个性化信息通常应谨慎缓存，列表数据则可能需要短期新鲜度和后台更新策略。判断是否能复用时，要考虑账号、权限、语言、筛选条件和服务端版本；缓存键遗漏任何一个维度，都可能把不该共享的数据展示给错误场景。

离线能力要先定义页面可用范围。完全离线可读、仅显示上次访问内容、允许离线编辑是不同目标；缓存壳并不代表核心业务已离线可用。服务工作线程的安装、激活和更新要考虑旧页面仍在运行的情况，版本切换时不要让新旧缓存混用。缓存空间可能被浏览器回收，应用不能把持久化成功当作永久保证，关键写操作应在界面明确待同步状态。

缓存更新策略存在新鲜度和等待时间的取舍。优先网络策略适合必须读最新状态的数据，但弱网下会延迟展示；优先缓存可以快速显示，却需要后台校验和更新提示。过期时长应根据业务变化速度确定，页面应说明数据是否为上次结果，并提供用户主动刷新入口。并发更新时要防止较旧响应覆盖较新缓存，可比较版本、更新时间或请求序号。

离线写入更需要谨慎。每条待同步操作应具备本地标识、创建时间、目标实体和可判定的重放语义；提交成功后才从队列清除。账号退出、权限变化或数据被服务端删除时，要暂停重放并展示冲突处理。队列中不应存放不必要的敏感字段，且应设定容量边界和清理规则，避免长期积累。

测试覆盖首次安装、升级、离线启动、恢复网络、浏览器清理存储和多标签页并发。特别验证应用更新后旧缓存能否安全迁移，失败时是否保留可用版本。将缓存命中率与过期数据投诉、同步失败率共同观察，避免只追求命中数字而牺牲内容正确性。用户需要清除数据时，应用应提供可理解的入口并解释未同步内容的处理结果。

复核案例与后续维护

缓存数据需要明确来源和失效依据。由用户修改的草稿、服务端只读数据和公共静态资源具有不同的保留要求；账号退出时清理用户私有数据，不能误删公共资源缓存。缓存键要由规范化后的参数组成，排序、大小写和默认值处理一致，否则相同查询会产生多个副本，也可能让不同查询共用错误结果。

弱网和离线状态应通过真实页面行为呈现。网络请求超时后可以显示上次可用内容和更新时间，同时提供刷新；离线操作则应标出待同步，确保刷新页面后状态仍可恢复。浏览器有权清除站点存储，应用要处理数据丢失而不是假设缓存永远存在。存储空间不足时需优先保留未提交用户内容，并清理可重新获取的资源。

缓存与并发写入相互影响。多个标签页同时更新同一数据时，较旧响应不能覆盖较新结果；可以使用版本、时间戳或业务序号判断先后。后台更新和用户正在编辑的表单发生冲突时，应保留草稿并询问如何处理，而非静默替换。服务器数据更新后也要通知其他页面适当刷新。

缓存策略上线后，除命中率外还需观察过期数据展示、同步失败、恢复网络后的积压和存储异常。分组试验不同有效时间，并建立回滚开关；高命中却带来旧数据投诉说明策略不合适。离线能力应逐步扩展，从只读内容开始，再对重要写操作设计队列、冲突界面和可靠确认。

持续维护要点

多标签页和浏览器清理是离线缓存的重要边界。标签之间同时刷新数据时应协调版本，避免旧页面覆盖新缓存；存储被浏览器回收后要回到可联网重建的路径。用户清除站点数据时说明尚未同步草稿的影响，并提供可控的导出与删除方式。

验收补充

缓存数据的用户可见更新时间能降低误解。展示旧数据时注明其来源和刷新状态，刷新失败保留已有内容并允许再次尝试。删除或过期策略发布前用测试数据验证，确认重要草稿优先保留，可重新下载的公共资源则允许清理。

发布后的观察

发布缓存策略后按不同数据族观察实际效果。静态资源命中提高不应伴随用户资料过期增长，离线页面可用也不代表待同步队列可靠。建立缓存内容清单和责任人，过期删除、账号切换和版本升级分别有验证步骤；发现旧值覆盖新值时能定位生成时间和来源。

总结

缓存策略要按资源时效和离线需求分别设计。长期缓存适合内容哈希资源，动态与私有数据需要更严格的失效规则；离线页面要说明数据新鲜度，更新和迁移流程要避免版本混杂。