Meta标签的Cache-Control对离线应用包版本一致性完全无效，因其仅影响HTML文档的HTTP缓存提示，而Service Worker的Cache API与HTTP缓存物理隔离，资源版本控制必须依赖SW脚本内的显式逻辑。
Meta 标签设置 Cache-Control 对离线应用包的版本一致性完全无效。 它既不能触发 Service Worker 更新，也不能阻止旧缓存干扰新版本，更不会影响 caches.open() 中已存资源的生命周期。
为什么 meta http-equiv="Cache-Control" 不参与离线版本管理
浏览器只把这类 meta 当作对当前 HTML 文档的“缓存提示”，且仅在无服务端响应头时才可能参考——而 Service Worker 的缓存（Cache API）是完全独立的存储空间，和 HTTP 缓存层物理隔离。你改了 content="max-age=0"，caches.match('/app.js') 仍会返回上次 cache.put() 存进去的旧二进制内容。
- Service Worker 安装时调用
cache.addAll()，存的是 fetch 到的完整响应体，不读取也不受 HTML 中任何meta影响 - 更新 SW 脚本本身靠字节比对，不是靠 HTML 里写了什么；新 SW 激活后，旧缓存仍躺在
cacheStorage里，除非你在activate事件里显式caches.delete() -
meta http-equiv对 JS/CSS/图片等外链资源毫无约束力——它们的缓存策略由各自请求的响应头决定，HTML 文档里的 meta 不会“传染”过去
Cache-Control 响应头才是关键控制点，但只作用于网络阶段
真正影响离线包一致性的，是服务器返回资源时的 Cache-Control 响应头，但它只起两个作用：一是决定浏览器是否从 HTTP 缓存加载资源（影响首次注册 SW 时的 fetch() 结果），二是防止资源被标记为 no-store 导致 cache.addAll() 直接失败。
-
Cache-Control: no-store→cache.addAll(['app.js'])报错，install 卡住 -
Cache-Control: max-age=3600→ 若用户在 1 小时内刷新，fetch('/app.js')可能直接走 HTTP 缓存，拿到旧版文件再存进 Cache API -
Cache-Control: immutable→ 不影响离线行为，只让浏览器跳过后续验证，但 SW 仍按你代码逻辑存/取
保证离线包版本一致的唯一可行做法
必须靠 Service Worker 脚本内部的显式版本控制，HTML 和 meta 标签无法替代。
立即学习“前端免费学习笔记（深入）”；
- 给缓存命名带版本号：
caches.open('v2-offline-cache')，避免和v1-offline-cache混用 - 在
install事件中预缓存时，确保所有路径是绝对根路径（'/index.html'✅，'./style.css'❌），且资源实际存在、返回 200 - 在
activate事件中清理旧缓存：caches.keys().then(keys => Promise.all(keys.map(key => key !== 'v2-offline-cache' ? caches.delete(key) : Promise.resolve()))) - SW 脚本自身更新需满足：文件内容有差异 + 页面刷新或调用
skipWaiting()+controllerchange事件监听接管完成
真正容易被忽略的是：即使你把 HTML 里所有 meta 都删光，只要 Service Worker 的缓存逻辑写得严谨，离线版本就能保持一致；反过来，哪怕 meta 写满十行，只要 sw.js 里没做 activate 清理，旧缓存就永远留在那里，等着干扰下一次更新。
