service worker 不支持 http cache-control 的自动过期，而是通过策略驱动的主动管理实现缓存更新：静态资源用哈希文件名+cache-first，html 用 stale-while-revalidate，api 用 network-first 加时间戳校验，实时数据禁用缓存；版本升级时通过 activate 阶段清理旧缓存。

Service Worker 本身不提供“缓存过期时间”（如 max-age）的直接配置——它不读取也不强制执行 HTTP 的 Cache-Control 头。所谓“过期策略”，其实是通过代码逻辑控制资源何时被替换、清理或跳过缓存，本质是**策略驱动的主动管理**，不是被动等待 TTL 到期。

按资源类型匹配对应策略

不同资源更新频率和一致性要求差异大，硬套统一过期规则会出问题。关键是把“过期”转化为“何时该重新拉新”：

deep-java-review

Java项目代码review工具。分析Git变更+完整调用链路上下文，推断业务需求，进行多维度评分和分类汇总，生成完整PRD文档。包含细粒度Java代码审查清单（Null安全、异常处理、Streams、并发、equals/hashCode、资源管理、API设计、性能、MyBatis/ORM、事务边界、SQL/DD...

下载

• 静态资源（JS/CSS/图片/字体）：靠文件名哈希区分版本（如 app.a3f2.js），天然无过期问题。用 Cache-First 策略即可，只要 URL 不变，就一直用缓存；URL 变了，浏览器自动请求新资源，旧缓存可后续清理。
• HTML 入口页：不能走 Cache-First（否则永远打不开新版）。推荐 Stale-While-Revalidate：立即返回缓存 HTML，同时后台 fetch 新版并更新缓存，下次访问就是最新版。
• API 数据（用户列表、订单状态等）：需要新鲜度。用 Network-First，设置合理超时（比如 3 秒），失败才 fallback 到缓存；也可加逻辑判断缓存是否“太老”（比如存入时间超过 5 分钟），强制走网络。
• 实时敏感数据（支付结果、聊天消息）：禁用缓存，用 Network-Only；或结合内存缓存 + WebSocket 主动失效，不依赖 Service Worker 缓存。

用缓存命名+激活阶段清理旧缓存

真正的“过期”控制发生在版本升级时。每次发布新版本，改缓存名（如从 v1 → v2），并在 activate 阶段删掉旧缓存：

• 安装时打开新缓存（caches.open('v2')），预加载新版资源；
• 激活时遍历所有缓存名，删除不含 v2 的旧缓存（caches.delete('v1')）；
• 这样旧资源彻底下线，不存在“过期但还留着”的情况。

给 API 缓存加时间戳判断

对必须带时效性的接口响应，可在缓存时存入时间戳，读取时做判断：

• fetch 后，用 response.clone() 生成两份响应；
• 一份写入缓存，另一份解析 JSON，把当前时间写进自定义 header 或包装成对象（如 { data: ..., timestamp: Date.now() }）再存；
• 下次 caches.match() 拿到后，先检查 timestamp 是否超时（比如 > 10 分钟），超时就忽略缓存，直接 fetch。

避免常见陷阱

• 别在 fetch 事件里对所有请求都走 caches.match() + fetch() 回退——没区分资源类型，容易把 HTML 缓死；
• 别依赖 Cache-Control: max-age=3600 让 Service Worker “自动过期”，它只影响浏览器 HTTP 缓存，不影响 Cache API；
• 本地开发时记得勾选 Chrome DevTools 的 “Update on reload”，否则新 SW 不会立即激活，改了策略也看不到效果。

Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南