Cache API 是 Service Worker 中专用于资源级缓存的核心工具，需在 install/activate/fetch 钩子中主动调用，支持按版本命名缓存、精准匹配请求，并配合 fetch 事件实现 Cache-first、Network-first 等策略。
Cache API 是 Service Worker 实现可控、可编程本地存储的核心工具，它不依赖用户操作或浏览器策略，而是由开发者主动调用，把网络请求和响应成对存进缓存空间。它和 localStorage 或 IndexedDB 的定位不同：Cache API 专为“资源级缓存”设计，天然适配 HTTP 请求/响应模型，能直接缓存 HTML、CSS、JS、图片甚至 API 返回的 JSON，且支持离线读取。
缓存生命周期必须绑定 Service Worker 阶段
Cache API 不会自动运行，必须在 Service Worker 的生命周期钩子中调用：
-
install 阶段：适合预加载关键静态资源（如首页 HTML、主样式、核心 JS）。用
caches.open()创建缓存，再用cache.addAll()批量写入。这一步失败会导致 SW 安装失败，所以建议只放确定不变的资源。 -
activate 阶段：适合清理旧缓存。比如从
v1升级到v2后，遍历caches.keys()，删除不再使用的缓存名，避免磁盘占用累积。 -
fetch 阶段：这是 Cache API 发挥作用的核心场景。通过
caches.match(request)查找匹配缓存，再用fetch(event.request)回源，最后组合出响应逻辑——比如先返回缓存、再后台更新（Stale-while-revalidate），或优先网络、失败才兜底缓存（Network-first）。
缓存命名要有版本意识和语义区分
Cache API 的缓存名是字符串，但不能随便起。推荐按“用途+版本”组合，例如：
-
static-v1：存放 CSS/JS/字体等长期不变资源，配合 Cache-first 策略； -
pages-v2：存放 HTML 页面，每次发布新版本时升级名称，确保旧页面不会干扰新逻辑； -
api-v1：缓存接口响应，适合搭配 Network-first 或 Stale-while-revalidate，避免数据陈旧。
不建议共用一个缓存名存所有资源——更新某类资源时无法精准清理，容易导致缓存污染或失效延迟。
缓存内容要与请求完全匹配才能命中
Cache API 的 match() 默认按 URL 和请求方法（GET/POST）匹配，但不校验请求头、查询参数顺序或 body 内容。这意味着：
- 带时间戳参数的请求（如
/data.json?t=123）会被视为新请求，即使资源没变； - POST 请求默认不被缓存（Fetch 规范限制），需手动构造 Request 对象并指定
cache: 'no-store'才能绕过； - 若需忽略某些查询参数（如跟踪用的 utm_），可在 fetch 事件中标准化 URL 再匹配，例如用 URL 构造器剔除无关参数后再调
caches.match()。
配合 fetch 事件实现策略组合
真正让 Cache API “高效”的，不是存得多，而是用得准。典型策略示例：
-
Cache-first（静态资源）：
caches.match(req).then(res => res || fetch(req))； -
Network-first（API 数据）：
fetch(req).catch(() => caches.match(req))； -
Stale-while-revalidate（兼顾速度与新鲜度）：先返回
caches.match()结果，再用fetch()更新缓存，更新后可广播给页面提示“数据已刷新”。
这些逻辑全部写在 Service Worker 的 fetch 监听器里，无需改动业务代码，就能统一控制全站资源的获取路径。
