PWA让网页拥有原生体验

可视化演示

认识PWA本质

想象一下，你家附近有两家餐厅：一家是每天早晨支起棚子的临时摊位，营业时间短、刮风下雨就歇业、没法提前订位；另一家是固定的餐厅，有招牌、有菜单、能预约、雨天照样营业。传统网页就像临时摊位，而原生 App 就像固定餐厅。PWA 的野心，就是让网页这个“临时摊位”升级成“固定餐厅”——不需要下载、不需要安装，却拥有餐厅的全部体验。

从技术上讲，PWA 的全称是 Progressive Web App，即“渐进式 Web 应用”。“渐进”的含义是：它不要求你一次性拥有全部原生能力，而是根据浏览器的支持情况逐步增强。你能离线访问就享受离线，你能推送就收获推送，一切以“能用就行”为底线，以“体验更好”为目标。

PWA 的三大核心能力可以概括为：可靠（Reliable，离线也能打开）、快速（Fast，秒开页面）、沉浸（Engaging，像 App 一样可安装、可推送）。这三大能力分别由 Service Worker、Cache API、Web App Manifest、Push API 等技术支撑。相比传统网页，PWA 多了离线能力和安装入口；相比原生 App，PWA 无需应用商店审核、无需下载安装包、天然跨平台。

回到餐厅的比喻：可靠性是餐厅的“雨天也营业”，快速是“点菜即上菜”，沉浸是“熟客刷脸进门”。PWA 的每一件装备，都是为了把这三个维度做到极致。

营地蓝图Manifest

建营地之前，你需要先画一张蓝图：营地叫什么名字、挂什么招牌、刷什么颜色的漆、开门时展示什么欢迎画面。Web App Manifest 就是 PWA 的这张蓝图。它是一份 JSON 文件，告诉浏览器“我的应用叫什么、图标长什么样、主题色是什么、启动时全屏还是带地址栏”。

在代码层面，你需要在 HTML 的 <head> 中通过 <link rel="manifest" href="manifest.json"> 引入这份蓝图。Manifest 中最常用的字段包括：name（应用全名）、short_name（桌面显示短名）、icons（应用图标，通常提供 192px 和 512px 两种尺寸）、start_url（启动时打开的页面）、display（以 standalone 方式独立显示）、theme_color（顶栏主题色）和 background_color（启动画面背景色）。

当这份 Manifest 配置达标后，浏览器就会在地址栏或菜单中提示“安装应用”。在桌面端，用户可以将 PWA “安装”到桌面，生成一个图标；在移动端，可以像 App 一样添加到主屏幕。启动时，PWA 会以独立窗口展示，并显示配置好的启动画面，完全告别浏览器的地址栏，让用户产生“这就是一个 App”的错觉。

蓝图画好了，营地就有了“脸面”。但这张蓝图只能解决“看起来像 App”，要让营地真正运作起来，还需要一位能力超群的总管——Service Worker。

营地总管SW

一个营地要想二十四小时运转，需要一位总管。这位总管不睡觉、不下班、站在营地门口，替你把所有物资（请求）分类处理：有库存的走仓库（缓存），没库存的去采购（网络），采购失败的给备用方案。Service Worker（简称 SW）就是这位总管。它是浏览器在后台独立运行的一段 JavaScript 脚本，独立于页面、不依赖页面存在，即使页面关闭，它依然值守。

要请来这位总管，需要三步。第一步注册：在页面中调用 navigator.serviceWorker.register('/sw.js')，告诉浏览器“我要聘请一位总管”；第二步安装：浏览器下载 sw.js 脚本，SW 触发 install 事件，通常在这里预缓存静态资源；第三步激活：安装成功后 SW 触发 activate 事件，清理旧缓存并完全掌控页面，此时页面刷新后的所有请求都会经过 SW。

SW 最强大的能力是拦截请求。通过监听 fetch 事件，SW 可以决定每个请求是走缓存、走网络、还是走“缓存优先、网络兜底”的混合策略。这就是 PWA 离线的核心——不是浏览器“自动缓存”，而是 SW 这位总管在替你精准地管理每一次物资调度。

总管已经到位，接下来就是搭建仓库。仓库里放什么货、什么时候补货、什么策略出货，就对应了 PWA 的缓存策略。

物资仓库缓存

营地总管需要一个仓库来存放物资，Cache API 就是 PWA 的物资仓库。它是一个存储网络响应（Request/Response）的缓存系统，支持在 SW 中通过 caches.open() 打开仓库、cache.put() 存放物资、cache.match() 取出物资。

仓库管理的关键是出货策略——当用户请求一个资源时，是先看仓库（缓存）还是先看市场（网络）？常用的策略有两种。第一种是缓存优先（Cache First）：请求到达时先查缓存，命中就直接返回，没命中再去网络获取并顺手存入仓库。这种策略适合图片、CSS、JS 等不常变的静态资源，速度最快。第二种是网络优先（Network First）：请求先走网络，网络成功就用网络数据并更新缓存，失败才回退到缓存。这种策略适合 API 数据、文章内容等实时性要求高的资源。

除了存取和策略，仓库还需要定期清理。缓存不是越多越好，当 SW 新版本激活时，activate 事件中通常会删除旧版本的缓存仓库，防止磁盘空间膨胀。这就是为什么 PWA 的资源文件通常带版本号（如 app-v1.js），便于精确控制哪些缓存可以回收。

仓库已备齐物资，营地可以做到“自给自足”了。但一个只靠用户主动访问的营地，还算不上真正的原生体验——你能主动走进营地，但营地为什么不能主动联系你呢？

信鸽与车队

一个成熟的营地需要主动联系外界：天气变了放出信鸽提醒你加衣、你寄出的信件由车队在信号恢复时统一送达。Push API 是信鸽，Notification API 是鸽哨，Background Sync 是物流车队。

Push API 允许服务器主动向用户推送消息，即使网页处于关闭状态。流程是：SW 中通过 PushManager.subscribe() 向推送服务订阅，获得一个唯一的订阅标识；服务器拿着这个标识即可随时发送推送消息；当消息到达时，SW 的 push 事件被触发，再通过 Notification API 展示通知。这就好比你给了营地一只信鸽，营地任何时候都能飞鸽传书给你。

Notification API 用于展示系统级通知。在 SW 中监听 push 事件后，调用 self.registration.showNotification(title, options) 即可弹出通知，包含标题、正文、图标、点击跳转链接等。请注意，Notification 需要用户在页面中主动授权，这对应“你同意营地给你传信”。

Background Sync 解决的是“网络不好时的数据提交”。当用户离线时填写了一个表单，网页无法提交；Background Sync 会把这次提交“排队寄存”，等网络恢复后自动重试。原理是 SW 注册一个 sync 事件，浏览器在检测到网络连通时触发该事件，SW 在事件中完成数据同步。这在弱网环境（地铁、电梯、山区）中极大提升了表单提交的成功率。

信鸽与车队到齐，营地已经能主动联系用户、离线提交数据。但这一切配置是否合格？这需要一位独立的质检员来验收打分。

营地质检员Lighthouse

营地建成后，你需要一位质检员从头到尾检查一遍：蓝图是否清晰、总管是否尽责、仓库是否高效、信鸽是否畅通。Lighthouse 就是 PWA 界的质检员。它是谷歌开源的一款自动化审计工具，可以对网页进行全方位体检并打分。

Lighthouse 的 PWA 审计项涵盖多个维度。以 Chrome 浏览器为例，打开 DevTools → Lighthouse → 勾选 PWA → Generate Report，就能得到一份 PWA 评分报告。核心检查项包括：是否注册了 Service Worker、Manifest 是否配置完整、是否支持离线访问、启动画面是否配置、图标尺寸是否达标、页面是否使用 HTTPS。每一项都有对应的权重，最终生成 0-100 的 PWA 得分。

得分之外，Lighthouse 还会给出最佳实践和性能建议，比如：资源是否启用缓存、图片是否压缩、第三方脚本是否拖慢加载。对开发者而言，Lighthouse 的意义在于“可量化的质量标准”——你不需要靠感觉判断 PWA 做得好不好，一份报告就告诉你哪里扣分、为什么扣分、怎么修复。

至此，六大部件全部到位：认识本质、Manifest 蓝图、SW 总管、缓存仓库、推送同步、Lighthouse 质检。从一座临时帐篷到一座移动营地，PWA 用一套渐进增强的装备，真正让网页拥有了原生的体验。你需要做的，就是拿起这份营建手册，亲自动手搭一座自己的营地。

AI 应用场景

Python 演示

# -*- coding: utf-8 -*-"""PWA 缓存策略模拟器：模拟 Service Worker 的缓存优先调度"""import timefrom collections import OrderedDict  class CacheStore:    """模拟 Cache API 的仓库"""     def __init__(self, name):        self.name = name        self._store = OrderedDict()     def put(self, url, content):        self._store[url] = content     def match(self, url):        return self._store.get(url)     def size(self):        return len(self._store)  class ServiceWorkerSimulator:    """模拟 Service Worker 的请求调度器"""     def __init__(self):        self.cache = CacheStore("my-site-v1")        self.network_hit = 0        self.cache_hit = 0        self._miss = 0     def install(self, assets):        """install 阶段：预缓存核心资源"""        for url, content in assets.items():            self.cache.put(url, content)     def _fetch_from_network(self, url):        """模拟网络请求，带固定延迟"""        time.sleep(0.01)        return "<html>网络响应: " + url + "</html>"     def fetch(self, url):        """fetch 事件：缓存优先，未命中走网络并回填缓存"""        cached = self.cache.match(url)        if cached is not None:            self.cache_hit += 1            return cached        response = self._fetch_from_network(url)        self.cache.put(url, response)        self.network_hit += 1        return response     def stats(self):        total = self.cache_hit + self.network_hit        hit_rate = (self.cache_hit / total * 100) if total else 0.0        return {            "总请求数": total,            "缓存命中": self.cache_hit,            "网络请求": self.network_hit,            "命中率": "%.1f%%" % hit_rate,            "仓库容量": self.cache.size(),        }  if __name__ == "__main__":    # 安装 SW：预缓存核心资源    sw = ServiceWorkerSimulator()    core_assets = {        "/index.html": "<html>首页（本地缓存版）</html>",        "/app.js": "console.log('app js')",        "/style.css": "body { color: #818CF8; }",    }    sw.install(core_assets)     # 模拟 10 次页面资源请求    request_urls = [        "/index.html", "/app.js", "/style.css",        "/api/products", "/index.html", "/api/products",        "/app.js", "/style.css", "/index.html", "/api/user/profile",    ]    for url in request_urls:        sw.fetch(url)     print("=== PWA 缓存策略模拟结果 ===")    for key, value in sw.stats().items():        print(f"{key}: {value}")

1. self.cache = CacheStore("my-site-v1")创建一个 Cache API 风格的仓库，对应浏览器中的 caches.open('my-site-v1')。
2. def install(self, assets)模拟 SW 的 install 事件，预缓存页面骨架、JS、CSS 等核心资源“备货”。
3. self.cache_hit += 1每命中一次缓存记一次数，对应浏览器性能面板中的"disk cache hit"。
4. response = self._fetch_from_network(url)缓存未命中时回退到网络请求，这就是 Cache First 策略的“兜底”。
5. hit_rate = (self.cache_hit / total * 100)计算缓存命中率，Lighthouse 报告中同样关注这个指标来判断缓存策略是否合理。

常见误区

面试题