直接回答：Service Worker 是页面与网络之间的可编程代理，缓存策略按资源类型选：入口 HTML 用 network-first（或 stale-while-revalidate），保证新版本可达；带哈希的静态资源用 cache-first 长缓存（内容变了哈希就变，天然安全）；API 数据按业务选 stale-while-revalidate（先给旧数据再后台刷新）；离线兜底页在最后 fallback。核心原则是“永不缓存不可变的反向”：HTML 一旦被长缓存，用户就被钉死在旧版。

展开解析：更新机制与坑：SW 脚本字节级对比触发更新，但新 SW 默认要等所有旧版标签页关闭才 activate（等待态）——这就是“发了版用户不更新”的经典坑，skipWaiting + clientsClaim 可立即接管，但跨版本缓存格式变化时要小心新旧混用；稳妥做法是注册监听 controllerchange 后提示用户刷新（或静默刷新一次）。缓存地狱的其他来源：缓存配额无上限膨胀（设 LRU 清理与总量上限）、API 缓存了带鉴权的响应（永存私有数据风险）、SW 自身的 bug 把所有请求搞挂（需要自毁开关：一个紧急空 SW 替换路径，配合 kill switch 接口）。灰度：SW 脚本本身走 CDN 短缓存发布，可按比例下发不同 SW；Workbox 把上述策略与陷阱封装成成熟方案，手写 fetch 事件处理前先用它。调试靠 DevTools 的 Application 面板与 chrome://serviceworker-internals。

追问方向：stale-while-revalidate 的一致性问题怎么处理？SW 与 HTTP 缓存如何配合不打架？

（约 500 字）