缓存优先必须在fetch事件中显式调用caches.match()并用event.respondwith()包裹，否则不生效；caches.match()返回undefined主因是request被重复读取、url参数不匹配、install未成功写入或请求非同源get。
缓存优先不是自动生效的，必须在 fetch 事件里显式调用 caches.match() 并用 event.respondWith() 包裹返回逻辑，否则浏览器照常走网络。
为什么 caches.match() 总是返回 undefined
最常见原因是 Request 对象被重复读取 —— 比如你先传给 cache.match(request)，又拿同一个 request 去 fetch(request)，就会报 Failed to execute 'fetch': Request has already been read。
- 必须在使用前调用
request.clone()：一个用于匹配缓存，另一个用于发起网络请求 -
cache.match()默认严格比对 URL 全路径（含查询参数）、HTTP 方法、请求头；缓存了/logo.png，但请求是/logo.png?v=2就不命中 - 可加选项放宽匹配：
caches.match(request, { ignoreSearch: true })忽略 query string，{ ignoreMethod: true }把 GET/HEAD 视为等价 - 确保
install阶段已成功写入该资源：路径必须是根相对路径（如'/index.html'），不能是'./index.html'或'index.html'
install 阶段缓存失败却没报错
cache.addAll() 是原子操作：列表中任意一项 404、跨域无 CORS、响应状态非 2xx（比如服务端返回 302 重定向或 500 错误），整个调用就直接 reject，缓存一个文件都不会写入，且 Worker 卡在 installing 状态，后续 fetch 事件根本不会触发。
- 必须用
event.waitUntil()包裹caches.open().then(...addAll())，否则安装流程提前结束 - HTML 文件本身要显式列出（如
'/'或'/index.html'），它内部引用的 JS/CSS 不会自动递归抓取 - 检查服务器响应头：若
/返回的是 SSR 动态页且带Cache-Control: no-store，addAll()会静默失败 - 开发时建议加校验：在
install前fetch(url).then(r => r.ok ? ... : console.error('fail:', url))
哪些请求不该进缓存优先逻辑
缓存优先只适用于同源、可克隆、只读的 GET 请求。把动态接口或非 GET 请求塞进去，轻则失效，重则污染缓存或导致白屏。
- 先过滤方法：
if (event.request.method !== 'GET') return fetch(event.request) - 按
event.request.destination分流：'document'可走 stale-while-revalidate；'script'/'style'应严格缓存；'json'/'empty'建议跳过缓存直连网络 - 避免缓存带查询参数的 API（如
/api/user?id=123）：cache.match()默认按完整 URL 匹配，参数不同即新键，极易撑爆缓存空间 - 跨域资源需服务端支持 CORS，且响应头含
Access-Control-Allow-Origin，否则fetch()阶段就失败，更别说缓存
真正难的不是写几行 caches.match()，而是判断哪个请求该缓存、用什么策略、什么时候清理——尤其是 activate 阶段不删旧缓存，caches.keys() 会越积越多，最终匹配变慢甚至出错。
大量免费API接口：立即使用
涵盖生活服务API、金融科技API、企业工商API、等相关的API接口服务。免费API接口可安全、合规地连接上下游，为数据API应用能力赋能！
