ExpirationPlugin 不会自动清理过期缓存，仅在缓存命中时顺带检查；适用静态资源，不适用强时效数据；需确保路由匹配正确、统一使用 Workbox 策略写入缓存。
Workbox ExpirationPlugin 不会自动触发清理，只在缓存命中时顺带检查
很多人以为 ExpirationPlugin 像定时任务一样定期扫库删旧数据，其实不是。它只在 caches.match() 成功返回某条缓存后，才顺手判断这条缓存是否过期；如果没被读取，哪怕过期一年也不会删。这是最常被误解的一点。
- 适用场景：适合「读多写少」的静态资源（如 CSS、JS、图片），靠用户访问自然淘汰
- 不适用场景：token、临时状态、API 响应等需要强时效控制的数据——这类必须用 IndexedDB + 时间索引主动查删
- 注意
maxAgeSeconds是从写入时间算起，不是从首次匹配算起；maxEntries是总条目上限，超了就按 LRU 清最久未用的
配置 maxAgeSeconds 后仍返回过期内容？检查 fetch 事件拦截顺序
如果你发现明明设置了 maxAgeSeconds: 3600，但离线打开页面还是加载了两天前的 JS，大概率是 workbox.routing.registerRoute 的匹配逻辑没兜住该请求，导致根本没走 ExpirationPlugin 流程。
- 确认路由规则中
request.destination类型匹配正确：JS 文件要匹配'script'，CSS 匹配'style'，字体匹配'font' - 避免用通配正则（如
/\.(js|css)$/）却没限制destination，否则可能把POST /api/login也误判为脚本请求 - 调试技巧：在
fetch回调里加console.log(event.request.url, event.request.destination)，看实际请求是否进了你配的 route
想强制清理过期缓存？得手动调用 caches.keys() + caches.delete()
ExpirationPlugin 不提供外部触发的清理接口。真要批量删过期项（比如用户点击「清空缓存」），只能自己遍历 cache 名称、打开 cache、逐条读 response.headers.get('date') 或解析自定义 header（如 x-cache-timestamp）来判断。
- 更可靠的做法：在缓存时用
cache.put(request, response.clone().headers.set('x-cache-timestamp', Date.now().toString())) - 清理函数里用
cache.keys().then(keys => Promise.all(keys.map(key => { /* 检查 header + delete */ }))) - 注意：
caches.delete()是异步的，别在 Service Worker install 阶段直接 await，会阻塞激活
和 Cache API 原生用法混用时，ExpirationPlugin 完全失效
一旦你在同一个 cache 中，既用 workbox.strategies.cacheFirst({ plugins: [...] }) 写入，又用原生 caches.open('my-cache').then(cache => cache.put(...)) 写入，ExpirationPlugin 对后者完全无感知——它只在 Workbox 封装的策略链路里生效。
立即学习“前端免费学习笔记（深入）”；
- 所有缓存写入必须统一走 Workbox 策略（
cacheFirst、staleWhileRevalidate等） - 不要在 SW 里手动
caches.open().put()存 HTML 或 JS，除非你同时自己实现时间戳校验逻辑 - 如果要用原生 API 做特殊处理（比如动态生成响应），建议单独建一个不带插件的 cache，比如
'runtime-manual-cache'，和 Workbox 管理的 cache 隔开
真正难的不是配参数，而是想清楚：哪些资源该由 Workbox 自动管生命周期，哪些必须自己控——比如用户上传的草稿、登录态 token，永远不该进 Cache API。
