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>、关键图片）列全，路径用根相对路径（如'/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 里，就只能靠发新版本覆盖，没法热更新。
