离线体验关键在于HTML的network-first缓存策略、表单数据本地持久化至IndexedDB、以及针对iOS限制的主动降级处理。
离线体验不是“加个 serviceWorker.register() 就完事”，核心在于缓存策略是否匹配资源特性，以及用户断网时有没有真正可用的响应。
如何让 HTML 页面在断网时还能打开
关键不是预缓存所有 HTML，而是对 HTML 资源采用 network-first 策略：每次访问都先尝试网络请求，成功则返回并更新缓存；失败则 fallback 到最近一次缓存的 HTML 版本。
- 直接
cache.addAll(['index.html'])预缓存是危险的——HTML 通常带动态内容（如时间戳、用户状态），缓存旧版会导致空白、错乱或 404 - 必须在
fetch事件中显式处理 HTML 请求，不能依赖 Workbox 默认的StaleWhileRevalidate对所有资源一视同仁 - 建议为 HTML 单独开一个缓存空间（如
'html-cache-v2'），避免和静态资源混在一起导致误删 - 首次安装 PWA 时若用户已断网，需提供一个兜底的
offline.html，并在caches.match()失败后返回它
为什么 CSS/JS 要用 cache-first，而接口数据不能这么干
CSS 和 JS 属于「强一致性静态资源」：内容不变、版本由文件名或 hash 控制，本地缓存可长期复用；但接口返回的 JSON 数据是「弱一致性动态内容」，缓存过期会导致用户看到陈旧订单、未更新的消息。
- CSS/JS 缓存可设为 7 天以上，配合文件内容哈希（如
main.a1b2c3.js）实现自动版本隔离 - 接口请求建议用
network-only或network-first+ 短期 TTL（如 5 分钟），通过CacheStorage.put()手动写入时带上时间戳，读取前校验是否超时 - Workbox 的
CacheableResponsePlugin对接口不适用——它只检查 HTTP 状态码，不判断业务时效性 - 不要把整个 API 响应体无差别塞进 Cache API；敏感字段（如 token、临时链接）必须过滤或加密后再缓存
表单提交离线后怎么不丢数据
不能靠 Service Worker 拦截 fetch 并重试——Background Sync 在 iOS 上根本不可用，且 Chrome 也只在页面处于活跃标签页时才可能触发 sync 事件。
立即学习“前端免费学习笔记（深入）”；
- 前端提交前先写入
indexedDB，每条记录标记status: 'pending'和timestamp - 提交按钮点击后立即置灰 + 显示「已保存，联网后同步」，防止重复点击
- 用
navigator.onLine监听网络恢复，触发批量同步；失败则保留pending状态，下次启动再试 - Service Worker 内不要尝试发请求同步表单——它大概率已被系统终止（尤其 iOS 下关闭标签页后 30 秒内）
- IndexedDB 并发写入需用
transaction包裹，否则多窗口同时提交可能覆盖彼此数据
最常被忽略的一点：离线体验的好坏，不取决于你缓存了多少，而取决于用户断网那一刻，他正在操作的页面是否真能继续用。HTML 文件的缓存策略、表单数据的本地持久化路径、以及对 iOS 限制的主动降级处理，这三处不细抠，其他优化都是纸面功夫。
