CacheStorage 是 Service Worker 中需开发者主动管理静态资源缓存的核心 API，通过 caches.open() 创建语义化命名的 Cache 实例，手动调用 addAll()/put() 写入、match() 匹配（需标准化请求）、activate 阶段清理旧缓存，无自动过期机制。
CacheStorage 是 Service Worker 中用于管理静态资源缓存的核心 API，它不自动缓存任何内容，而是由开发者显式控制哪些资源进缓存、何时更新、如何匹配和删除。关键在于“主动管理”——不是配置开关，而是编写逻辑来决定缓存生命周期。
缓存的创建与命名有明确语义
CacheStorage 通过 caches.open(cacheName) 获取一个 Cache 实例，cacheName 应体现用途和版本，比如 "static-v1" 或 "fonts-preload-2024"。避免使用固定名称如 "cache"，否则升级策略时容易冲突。多个 cache 可共存，便于灰度迁移或按类型隔离（如分开缓存 CSS、JS、图片）。
资源写入需手动触发，支持批量与条件判断
缓存静态资源不能依赖浏览器默认行为，必须在 install 或 fetch 事件中调用 cache.addAll() 或 cache.put()：
- addAll() 适合预加载已知资源列表（如构建时生成的 manifest），失败则整个操作回滚；
- put(request, response) 更灵活，可用于动态构造响应（例如 fallback 图片、内联 SVG 响应）；
- 建议对 HTML 页面等关键资源做 stale-while-revalidate：先返回缓存，再后台拉新版本并更新缓存。
缓存匹配要兼顾请求方式与完整性校验
cache.match(request) 默认只比对 URL，但实际中常需扩展匹配逻辑：
立即学习“Java免费学习笔记（深入）”；
- GET 请求可忽略 URL 中的随机参数（如 ?t=123），用 new Request(urlWithoutQuery, { method: 'GET' }) 标准化后再匹配；
- 对于带 CORS 的资源，确保 request 的 mode 和 credentials 与缓存时一致，否则 match 失败；
- 若资源启用 Subresource Integrity（SRI），可在 put 前校验 integrity，避免缓存损坏副本。
旧缓存清理需主动执行，不可依赖自动过期
CacheStorage 没有 TTL 或 LRU 自动淘汰机制。升级版本后，应在 activate 阶段清理旧 cache：
- 监听 self.addEventListener('activate', e => {...})；
- 调用 caches.keys() 获取所有 cache 名称，用 Promise.all(cachesToDelete.map(name => caches.delete(name))) 批量删除；
- 注意：delete 操作会等待当前所有 fetch 使用该 cache 结束后才真正释放，安全可靠。
不复杂但容易忽略——CacheStorage 的力量不在自动化，而在可控性。把缓存当作状态来管理，每次 install、fetch、activate 都是明确的状态转换点。
