Service Worker 无法实现“永不过期”缓存,因 Cache-Control: immutable 仅影响浏览器条件请求,不阻止 SW 主动删除或解决 URL 变更问题;真正长期驻留需靠版本化 cacheName(如 static-v1.2.0)、install 预缓存、activate 阶段精准清理旧缓存,并标准化请求 URL 以确保 match 成功。

Service Worker 无法真正实现“永不过期”缓存,但可以通过 caches.open() + 版本化命名 + 显式不清理,让特定静态资源在用户设备上长期驻留——前提是开发者主动控制生命周期,而非依赖浏览器自动过期。
为什么不能靠 Cache-Control: immutable 实现“永不过期”
Cache-Control 的 immutable 是 HTTP 层的提示,只影响浏览器是否发起条件请求(如 If-None-Match),但它不阻止 Service Worker 主动调用 cache.delete(),也不影响 caches.keys() 列出的 cache 名称。更关键的是:immutable 要求资源 URL 永远不变,而实际项目中一旦 JS/CSS 更新,必须换 URL(否则用户永远拿不到新版)。所以它和 SW 缓存是两套机制,混用反而容易错乱。
常见错误现象:
- 给未哈希的
app.js加了Cache-Control: max-age=31536000, immutable,更新后用户仍加载旧版,且无法通过skipWaiting()强制刷新 - SW 中用
caches.open('static')写入资源,但后续升级时没清理旧 cache,导致磁盘占用持续增长,甚至触发浏览器自动回收
用版本化 cacheName 实现语义化“长期驻留”
所谓“永不过期”,本质是让某一批资源在用户设备上尽可能久地存在,直到你明确决定淘汰它。这靠的是 cache 名称的版本控制,而不是时间戳或随机字符串。
实操建议:
- 命名格式统一为
static-v1.2.0或assets-202604,其中版本号/日期来自构建产物 manifest 或 CI 环境变量,确保每次构建产出唯一 cacheName - 在
install事件中只写入当前版本资源,不要复用旧 cache;例如:caches.open('static-v1.2.0').then(cache => cache.addAll(['/css/main.css', '/js/app.js'])) - 避免使用
'static-cache'这类无版本名称——下次 install 时若仍用它,addAll()会覆盖已有条目,但旧资源响应体可能残留,造成 inconsistent state
match() 时忽略查询参数与标准化请求
静态资源 URL 常带构建哈希(如 /js/app.a1b2c3.js),但某些场景下会额外拼接调试参数(?debug=true)或埋点参数(&t=1713633681)。若直接用原始 Request 对象调用 cache.match(request),因 URL 不完全一致,匹配失败,导致回源。
解决方法是标准化请求再匹配:
- 提取 URL 主干:用
new URL(request.url).origin + new URL(request.url).pathname去掉 query 和 hash - 重建 Request 对象:
cache.match(new Request(cleanUrl, { method: request.method })) - 注意:若资源启用 CORS,需同步传入
credentials: request.credentials,否则 match 失败
示例片段:
self.addEventListener('fetch', e => {
const url = new URL(e.request.url);
if (url.pathname.startsWith('/js/') || url.pathname.startsWith('/css/')) {
const cleanUrl = `${url.origin}${url.pathname}`;
e.respondWith(
caches.match(new Request(cleanUrl, { method: 'GET', credentials: 'same-origin' }))
.then(r => r || fetch(e.request))
);
}
});
activate 阶段只删明确废弃的 cache
“长期驻留”不等于“永不清理”。旧 cache 必须在 activate 事件中显式删除,否则多个版本并存会浪费存储空间,极端情况下触发浏览器限制(Chrome 对单个 origin 的 cache 总量有隐式上限)。
关键点:
- 先获取当前所有 cache 名称:
caches.keys() - 只删那些不在白名单里的旧版本,例如保留
['static-v1.2.0', 'static-v1.1.0'],删掉static-v1.0.0 - 用
event.waitUntil(Promise.all([...]))确保删除完成后再激活新 SW,防止 fetch 使用中途被删的 cache - 不要在
install阶段删旧 cache——此时旧 SW 可能还在处理请求,delete()会失败或阻塞
最易被忽略的一点:即使你写了 caches.delete('static-v1.0.0'),浏览器也不会立刻释放磁盘空间;它会在所有对该 cache 的引用(包括正在运行的 fetch 请求)结束后才真正清理。所以“删了就立刻变小”是错觉。










