Service Worker 不支持 HTTP Cache-Control 的自动过期，而是通过策略驱动的主动管理实现缓存更新：静态资源用哈希文件名+Cache-First，HTML 用 Stale-While-Revalidate，API 用 Network-First 加时间戳校验，实时数据禁用缓存；版本升级时通过 activate 阶段清理旧缓存。
Service Worker 本身不提供“缓存过期时间”（如 max-age）的直接配置——它不读取也不强制执行 HTTP 的 Cache-Control 头。所谓“过期策略”，其实是通过代码逻辑控制资源何时被替换、清理或跳过缓存，本质是**策略驱动的主动管理**，不是被动等待 TTL 到期。
按资源类型匹配对应策略
不同资源更新频率和一致性要求差异大，硬套统一过期规则会出问题。关键是把“过期”转化为“何时该重新拉新”：
-
静态资源（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 阶段删掉旧缓存：
Alibabacloud Sdk Client Initialization For Java
下载
在 Java 中初始化和管理阿里云 SDK客户端。包括单例模式、线程安全、endpoint 与 region 配置、VPC 终端节点、同步与异步等。
- 安装时打开新缓存（
caches.open('v2')），预加载新版资源； - 激活时遍历所有缓存名，删除不含
v2的旧缓存（caches.delete('v1')）； - 这样旧资源彻底下线，不存在“过期但还留着”的情况。
给 API 缓存加时间戳判断
对必须带时效性的接口响应，可在缓存时存入时间戳，读取时做判断：
立即学习“Java免费学习笔记（深入）”；
- 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 不会立即激活，改了策略也看不到效果。
