html本身不参与fetch缓存策略执行,所有逻辑必须由service worker通过cache api显式控制,且meta标签无效;fetch默认走http缓存,需caches.open()和cache.put()才能写入cache storage,二者完全隔离。

HTML 本身不参与 fetch 缓存策略的执行 —— 所有缓存逻辑必须由 JavaScript(通常是 Service Worker)通过 Cache API 控制,且不能依赖 HTML 标签或 meta 声明。
fetch 请求怎么进 Cache Storage 而不是浏览器 HTTP 缓存
浏览器默认对 fetch 请求走 HTTP 缓存(disk/memory cache),但 Cache API 是独立存储空间,需显式调用 caches.open() + cache.put() 才会写入。常见错误是只发 fetch() 却没 cache.put(),结果资源看似“加载了”,却不在 Cache Storage 里。
- HTTP 缓存和 Cache Storage 完全隔离:一个资源可能同时存在于两者中,清理、更新、命中互不影响
-
fetch()默认仍受Cache-Control响应头约束;若服务器返回no-store,fetch就不会存到 HTTP 缓存,但你仍可手动cache.put()到 Cache Storage - 想绕过 HTTP 缓存直接走 Cache Storage?加
cache: 'reload'或cache: 'no-cache'选项强制网络请求,再自己决定是否存入 cache
Service Worker 里怎么正确缓存 HTML 及其依赖
直接 cache.addAll(['index.html']) 是错的 —— HTML 加载后会发起对 app.js、style.css 的子请求,这些请求若未提前缓存,离线时就会 404。
- 必须把 HTML 文件本身 + 它所有同步依赖(
<link rel="stylesheet">、<script src></script>、关键图片)列全,路径用根相对路径(如'/app.js'),不能用相对路径(如'./app.js') - 不要缓存带查询参数的 URL:
'/data.json?v=1.2'和'/data.json?v=1.3'在 Cache Storage 中是两个键,容易撑爆空间 - HTML 文件建议用 Stale-While-Revalidate 策略:先
caches.match()返回缓存,再fetch()更新缓存,避免白屏或阻塞渲染
fetch 事件中如何分流请求并避免缓存污染
不是所有请求都该进缓存。API 接口返回动态数据,缓存它会导致用户看到陈旧状态;而字体、图标等资源缓存太久又可能因版本不一致出问题。
- 按
request.destination分流最可靠:destination === 'document'处理 HTML,destination === 'script'或'style'可直取缓存,destination === 'json'或'empty'应优先走网络 - 不要无差别
caches.match(event.request)—— 这会把 POST 请求、带 cookie 的认证请求也匹配进去,导致安全或逻辑错误 - 对非 GET 请求(如
POST),caches.match()默认不匹配,但若你手动构造 Request 对象传入,可能意外命中,务必加if (event.request.method !== 'GET') return fetch(event.request)守门
缓存版本更新后怎么安全清理旧 cache
新 Service Worker 激活时,旧缓存不会自动删除。如果不清,多个版本 cache 并存会浪费空间,还可能导致页面加载时匹配到错误版本的资源。
- 清理动作必须放在
activate事件中,不能放install阶段 —— 否则旧 SW 还在运行,caches.delete()会失败 - 清理前要确认当前正在使用的 cache 名称(比如
'pages-v2'),只删不含该名称的 cache:!key.includes('v2')比硬编码['v1']更健壮 - 清理后建议调用
self.clients.claim(),让新 SW 立即接管已有页面,避免下次刷新才生效
真正麻烦的不是写几行 caches.open(),而是搞清每个资源该不该缓、什么时候缓、缓多久、从哪读、旧的怎么扔 —— 这些决策一旦写死在 SW 里,就只能靠发新版本覆盖,没法热更新。
大量免费API接口:立即使用
涵盖生活服务API、金融科技API、企业工商API、等相关的API接口服务。免费API接口可安全、合规地连接上下游,为数据API应用能力赋能!











