Cache API是Service Worker中实现离线缓存的核心，需在install阶段预加载静态资源、fetch阶段拦截请求并策略化缓存，配合版本命名与activate清理实现平滑升级，注意跨域、请求方法及Request复用限制。
在 Service Worker 中使用 Cache API 是实现离线资源缓存的核心方式。它不依赖浏览器默认缓存机制，而是由开发者显式控制哪些资源被缓存、如何匹配请求、怎样更新策略。
Cache API 的基本操作流程
Cache API 提供基于 Promise 的接口，在 Worker 内通过 caches.open() 获取缓存实例，再调用 put()、match()、delete() 等方法管理键值对（Request → Response）。每个缓存有唯一名称，可并存多个缓存空间，便于版本隔离或按类型划分（如 static-v1、images-v2）。
- 缓存需在
install事件中预加载关键静态资源（HTML/CSS/JS/图标等），用event.waitUntil()阻塞安装完成 - 在
fetch事件中拦截网络请求，优先尝试cache.match(request)查找缓存，未命中再发起网络请求并可选择性存入缓存 - 避免直接缓存所有请求——应过滤掉动态接口（如带 query 参数的 API）、跨域非 CORS 资源、POST 请求等不适用缓存的场景
缓存策略与版本控制
缓存名通常包含版本标识（如 'static-v2'），配合 install 和 activate 事件实现平滑升级：新版本缓存在 install 阶段创建并填充；activate 阶段清理旧缓存，防止冗余占用存储空间。
- 激活时遍历
caches.keys()，删除不匹配当前版本名的缓存 - 对 HTML 文件建议采用 Network-First 或 Stale-While-Revalidate 策略，确保用户始终看到最新结构；而 CSS/JS 可用 Cache-First，配合内容哈希命名规避更新失效问题
- 注意
cache.match()默认区分 HTTP 方法和请求头，若需宽松匹配，可传入{ ignoreMethod: true, ignoreSearch: true }选项
处理跨域与非 GET 请求
Cache API 只能缓存成功响应（status 200–299），且对跨域资源要求响应头含 Access-Control-Allow-Origin。非 GET 请求（如 POST）无法被缓存，也不应出现在 fetch 事件的缓存逻辑中。
- 图片、字体等跨域资源若未正确配置 CORS，可在
@font-face中添加crossorigin属性，并确保服务端返回对应头信息 - API 请求应明确跳过缓存逻辑，或使用单独的策略（如仅缓存特定只读接口，且设置合理 TTL）
- 注意
Request对象不可重复使用：若需同时用于 cache.match() 和 fetch()，须先调用request.clone()
调试与限制注意事项
Chrome DevTools 的 Application → Cache Storage 面板可直观查看各缓存内容及大小；但要注意缓存容量无统一标准，取决于设备存储与浏览器策略（通常为几十 MB 到数百 MB 不等）。
- 缓存写入失败不会抛出错误，需检查
await caches.open(...).then(cache => cache.put(...))的 Promise 是否 resolve - StorageManager 接口（
navigator.storage.estimate()）可用于估算可用空间，辅助做缓存清理决策 - 不要在主线程直接访问 Cache API —— 它仅限 Worker 环境（Service Worker 或 Worklet），且必须在 HTTPS（或 localhost）下启用
大量免费API接口：立即使用
涵盖生活服务API、金融科技API、企业工商API、等相关的API接口服务。免费API接口可安全、合规地连接上下游，为数据API应用能力赋能！
