网络优先和缓存优先是面向不同资源与场景的针对性选择：缓存优先适用于静态资源、离线页及预加载内容；网络优先适用于个性化数据、实时接口及身份相关动态内容；生产环境应采用按路径或类型分流的混合策略，并注重缓存命名隔离、清理时机和弱网测试。
网络优先和缓存优先不是非此即彼的取舍，而是面向不同资源类型、业务目标与用户场景的针对性选择。关键在于识别“什么内容必须最新”和“什么内容可以稍旧但必须快”。
缓存优先（Cache First）适合这些资源
核心逻辑：先查缓存，命中就返回；未命中再走网络，并把响应存入缓存供下次用。
- 静态资源：CSS、JS、字体、图标、Logo 等构建界面的基础文件，版本通常随部署更新，内容稳定
-
离线兜底页：如
/offline.html，需确保网络断开时仍能展示基础 UI -
预加载关键路径：首页 HTML、首屏图片等，安装阶段通过
caches.addAll()预置，保障冷启动体验
网络优先（Network First）适用这些场景
核心逻辑：先发网络请求；失败或超时才 fallback 到缓存——强调“新鲜度高于速度”。
- 用户个性化数据：个人中心信息、未读消息数、购物车状态等，延迟展示旧数据可能引发逻辑错误或体验错乱
- 实时性要求高的接口：行情报价、活动倒计时、在线客服状态等，缓存过期风险大于一次请求延迟
- 带身份上下文的动态内容：如登录态校验接口、权限菜单接口，服务端返回可能依赖 session 或 token 生效状态
混合策略才是生产环境的常态
单一策略难以覆盖全部流量。真实项目中建议按请求路径或资源类型分流：
-
静态资源走缓存优先：匹配
/static/.*、.*\.(css|js|png|woff2)等正则，使用CacheFirst策略 + 合理过期插件（如 Workbox 的ExpirationPlugin） -
API 接口按语义分层：GET 查询类（如
/api/articles）可设为网络优先 + 缓存 fallback；POST/PUT 类操作不缓存，直接透传 -
兜底离线页单独处理：对根路径
/或 404 请求，固定返回预缓存的离线 HTML，不依赖网络结果
上线前必须验证的三件事
策略选对只是起点，落地效果取决于执行细节：
-
缓存命名与版本隔离：每次更新缓存策略或资源内容时，务必变更 cache name（如
v202605-offline），避免旧缓存污染新逻辑 -
缓存清理时机明确：在
activate事件中遍历并删除旧 cache，防止磁盘占用无限制增长 - 真实弱网/断网测试不可跳过：用 Chrome DevTools 的 Network → Throttling 模拟 3G/Offline，观察首屏渲染、API 响应、错误提示是否符合预期
