PWA核心：Service Worker 与 Cache API

可视化演示

展示系统处理流水线、实时性能指标曲线及多方案对比分析，包含数据流转、吞吐延迟监控与方案评估。

认识站长：Service Worker 初探

普通网页脚本像驿站里的“临时工”——网页一关，人就下班，什么也干不了。站长不一样，他是 24 小时值班的经理：即使住户关灯睡觉（页面关闭），他仍在后台值班；第二天住户醒来，他早已把要用的东西备好了。这套“页面关了人还在”的能力，正是 PWA 离线体验的第一块基石。

这个“值班经理”在技术上叫 Service Worker，简称 SW。它是一段独立于网页的 JavaScript 脚本，由浏览器在后台单独维护。住户（页面）可以用一种特殊方式“聘请”他：调用注册接口，把站长安排到站点名下。此后，住户的一切取件需求都会先经过站长之手。

站长上岗有三条硬规矩。第一，他必须住在 HTTPS（或本地调试的 localhost）环境里——因为能拦截所有快递，浏览器绝不允许不可信来源聘用他。第二，他与页面不在同一个线程：页面崩溃不影响他值班，他也碰不到 DOM，只能通过消息与页面通信。第三，他有明确的上班流程，即生命周期：下载脚本后依次经历注册、安装、激活，之后进入闲置状态，等待 fetch（拦快递）、sync（补发）等事件召唤。

站长正式上岗了，但此刻他手里还没有任何货。要让住户“断网也能取件”，下一步得给他配一间能存能取的仓库——这正是 Cache API 的用武之地。

Cache 仓库：缓存 API 基础

站长光能拦截快递还不够，得有个地方存货。驿站角落那排贴着标签的货架，就是 Cache API：它以“请求”为钥匙、以“响应”为货物，是浏览器专门提供给站长使用的存储空间。没有它，站长就算拦下请求也无处安放货物。

这套货架用起来很直觉：caches.open('仓库名') 打开（没有就新建）一间仓库；cache.add('/a.css') 表示“这箱货直接上架”——同时完成从网络取货和入库两步；cache.put(请求, 响应) 则是手动上架，适合存放动态拼装的响应；cache.match(请求) 是取货；caches.delete('仓库名') 是整间仓库拆除。站长把这五招记熟，仓库管理就入门了。

需要特别注意的是，Cache 仓库和 HTTP 缓存是两回事：HTTP 缓存由浏览器根据响应头自动管理，开发者只能眼巴巴看着；Cache API 则完全听站长指挥——存什么、存多久、什么时候清，全部由代码说了算。为了便于日后整仓换新，仓库名的命名有一套约定俗成的公式。

货架备好了，但站长面对茫茫货品，怎么快速找到住户要的那一件？这就要靠“请求匹配”这枚钥匙了。

请求匹配：钥匙与锁

每件包裹上都缠着一张快递单，上面写着住户的地址和商品编号——这个“单号”就是请求的 URL。仓库里每件货物的标签是一把锁，只有单号对得上才能开锁取货。货再多，只要钥匙配得好，站长就能一秒锁定目标。

在代码里，与“开锁”对应的方法是 cache.match(request)。站长拿着住户的请求去仓库里逐一比对：能找到相同 URL 的条目，就算命中（hit），直接取货；找不到，就算未命中（miss），只能转向网络。这一步是后续所有缓存策略的“决策入口”。

匹配还支持“模糊钥匙”：通过 ignoreSearch 等选项，可以忽略 URL 中的查询参数（比如 ?track=123），让不同参数的请求共享同一件货。cache.keys() 能列出仓库里全部钥匙，常用于盘点货物是否齐全。衡量站长找货效率的核心指标是命中率——它直接决定页面加载是“秒开”还是“转圈”。

有了仓库和钥匙，还缺一本“取货守则”：什么时候先取货、什么时候先订货？这就是缓存策略——站长手里的四套预案。

缓存策略：四种决策

面对住户的每一个需求，站长心里有四套预案。第一套“缓存优先”：仓库有货就直接给，绝不惊动厂家；第二套“网络优先”：先给厂家打电话，打不通才回头用仓库货；第三套“旧缓存再验证”：先把仓库里的旧货递给住户，同时悄悄联系厂家补新货入库，下次就能拿新的；第四套“仅缓存/仅网络”：只适用于特殊商品，比如固定不变的 Logo 或必须实时的接口数据。

选哪套，取决于货物“多容易过期”。带指纹的静态资源（如 app.8f3c2a.js）几乎不变，适合缓存优先，秒开且省流量；HTML 页面和 API 数据变化快，适合网络优先或再验证，保证住户总能看到新鲜内容。现实中没人会全站只用一种策略，按资源类型混搭才是专业做法。

用代码表达，缓存优先策略就是一次条件判断：先查仓库，命中就返回；不命中才走网络，并把新货补进仓库。这构成 PWA 缓存逻辑的基本回路，其他策略都是在这条回路上调整判断顺序。

策略再好，仓库里的货也有过期的一天。站长还得定期对整个仓库“换新”——这就轮到版本更新登场了。

版本更新：仓库换新

驿站隔段时间就要盘点：旧货架规格过时了，站长就先在旁边搭一个全新的货架（新版本缓存），等新货架验收合格，再把旧货架整个拆掉扔进回收站。这样住户永远用新货，仓库也永远不会被陈年旧物塞满。

技术上的流程与之惊人相似：每次发布网站，开发者修改 sw.js 文件并递增缓存版本号。浏览器发现 sw.js 内容变了，就会下载新版脚本，让它进入安装阶段——此时旧站长仍掌管着页面，新旧站长之间有一段“交接期”。

新站长安装（install）时建立新版本仓库；激活（activate）时手持“白名单”巡检所有仓库，把不在名单里的旧仓库一键删除，释放磁盘空间。若想跳过交接期让新站长立刻接管，可以在安装事件里调用 skipWaiting()，并配合 clients.claim() 让新站长马上控制所有页面。

仓库换新解决了“货品过期”，但还没解决“住户断网时下的单子”。住户在没网时把一份订单塞进驿站信箱，站长要等网络恢复才能发出——这就是后台同步的拿手好戏。

后台同步：离线补发

深夜断电断网，住户没法联系厂家，只好把订单纸条塞进驿站门口的信箱——这个信箱就是“离线任务队列”。站长告诉住户：“放心，网络一恢复我马上发。”然后他继续值班，直到第二天网络恢复，一次性把积压的纸条全部打电话发出去。

技术上，这依赖 Background Sync API，分三步：第一步，页面在网络不可用时把要发送的请求登记进队列；第二步，调用 registration.sync.register('标签') 注册一个同步任务；第三步，浏览器监测到网络恢复后，触发 Service Worker 的 sync 事件，站长在事件回调里把队列中的请求逐个 fetch 出去。

补发并不保证一次成功。如果某个请求因网络仍不稳定而失败，队列会保留它，等待浏览器下一次触发 sync；多次失败后浏览器会停止重试，此时站长通常要给住户留一张“纸条”（通知），告知“有消息还没发出去”。这套机制让“断网时的用户操作不丢失”成为可能。

至此，站长能拦截、能存取、能换新、能补发，整个驿站运转起来了。但系统越复杂越要会“翻台账”——最后来聊调试方法与常见陷阱。

调试避坑：巡检清单

好站长每天都要巡仓、翻台账。浏览器的开发者工具就是站长的台账本：打开 DevTools 的 Application 面板，能查看 Service Worker 当前状态、手动注销站长、强制更新脚本、逐条查看仓库里的缓存货物。学会翻台账，排障就成功了一半。

最实用的排障套路是三板斧：先注销站长（Unregister），再清空缓存仓库（Clear storage），最后刷新页面重新注册。大部分“改了代码却不生效”的玄学问题，都能靠这套流程解决。它相当于把驿站推倒重建，让一切回到最干净的初始状态。

常见坑有三个：第一，以为注册了站长就等于离线，其实还要在 install 里预缓存、在 fetch 里拦截返回；第二，全站都用缓存优先，导致页面永远显示旧内容，HTML 该用网络优先；第三，更新了 sw.js 却忘了换版本号或清旧缓存，新货永远进不了仓。调试时用 Network 面板看请求是否走 Service Worker，用 Cache Storage 面板核对货架内容，就能快速定位问题。

从值班经理的聘用、仓库的搭建，到取货守则、换新机制、离线补发，再到最后的巡检台账——站长把驿站打理得井井有条。这套体系正是 PWA 离线体验的全部秘密：让网页像原生 App 一样，在弱网甚至断网时依旧从容。

---

AI 应用场景

Python 演示

import time  class CacheEntry:    """仓库里的一件货: 响应数据加入库时间"""     def __init__(self, data, ts):        self.data = data        self.ts = ts  class CacheStore:    """模拟 Cache API 的仓库, 以 URL 字符串为钥匙"""     def __init__(self):        self._items = {}     def match(self, url):        return self._items.get(url)     def put(self, url, data):        self._items[url] = CacheEntry(data, time.time())  class SimServiceWorker:    """站长模拟器: 内置三种缓存策略与命中率统计"""     def __init__(self):        self._cache = CacheStore()        self._latency = 0.05        self.hit_count = 0        self.net_count = 0     def _network(self, url):        if url.startswith("/api/offline"):            raise OSError("network down")        time.sleep(self._latency)        return "server:" + url     def preload(self, url, data):        """预缓存: 相当于 SW 安装阶段的 add 上架"""        self._cache.put(url, data)     def cache_first(self, url):        """缓存优先: 仓库有货直接用, 缺货走网络并入库"""        hit = self._cache.match(url)        if hit is not None:            self.hit_count += 1            return hit.data        data = self._network(url)        self._cache.put(url, data)        self.net_count += 1        return data     def network_first(self, url):        """网络优先: 先走网络, 失败回退仓库"""        try:            data = self._network(url)            self._cache.put(url, data)            self.net_count += 1            return data        except OSError:            hit = self._cache.match(url)            if hit is None:                raise            self.hit_count += 1            return hit.data     def stale_while_revalidate(self, url):        """旧缓存再验证: 先给旧货, 同时后台补新"""        hit = self._cache.match(url)        if hit is not None:            self.hit_count += 1            fresh = self._network(url)            self._cache.put(url, fresh)            return hit.data        data = self._network(url)        self._cache.put(url, data)        self.net_count += 1        return data     def hit_rate(self):        total = self.hit_count + self.net_count        return self.hit_count / total if total else 0.0  def main():    sim = SimServiceWorker()    urls = ["/img/logo.png", "/css/app.css", "/js/app.js"]    for _ in range(5):        for u in urls:            sim.cache_first(u)    total = sim.hit_count + sim.net_count    print("cache_first: requests", total)    print("cache_first: hit rate", round(sim.hit_rate(), 2))     sim2 = SimServiceWorker()    sim2.preload("/api/offline", "cached-offline-data")    print("network_first: fallback", sim2.network_first("/api/offline"))  if __name__ == "__main__":    main()

1. class CacheStore:模拟 Cache API 的仓库，内部用字典存储，URL 即钥匙
2. def cache_first(self, url):缓存优先策略：先 match 找货，缺货才走网络
3. hit = self._cache.match(url)拿 URL 钥匙在仓库找货，对应真实世界的 cache.match
4. data = self._network(url)模拟网络请求，/api/offline 会抛异常模拟断网
5. def network_first(self, url):网络优先策略：先上网，异常时回退仓库
6. except OSError:网络优先的“保险丝”：一旦断网就转向缓存兜底
7. def stale_while_revalidate(self, url):先返回旧货，同时后台拉新入库
8. print("cache_first: hit rate", round(sim.hit_rate(), 2))用命中率给策略“体检”

常见误区

面试题