Progressive Web Apps
先把 PWA 讲得现代一点
很多人讲 PWA，还是停留在一种很早期的语气里：
“让网页像原生 App 一样。”
这句话对传播很方便。
但在今天已经不够准确。
web.dev 对 Progressive Web App 的定义更有用。
它强调的是三件事：
- 通过渐进增强提供更可靠的体验
- 利用新能力提供更整合的体验
- 可以被安装
这个定义比“像原生 App”更稳。
因为它不会自动承诺：
- 所有平台都完全一致
- 所有浏览器都能安装
- 体验一定等同于原生
它更接近真实工程判断。
为什么 PWA 到今天仍然重要
有一种误解是：
App 生态已经很成熟，PWA 只是 Web 阵营的情怀概念。
这个判断太简单了。
PWA 的价值从来不只是“和原生竞争”。
它更大的意义在于：
Web 应用能不能在保留网页分发和链接能力的同时，获得更好的可靠性、离线能力、安装体验和设备整合能力。
这在很多场景里都很现实。
比如：
- 内容产品
- SaaS 工具
- 轻量协作工具
- 多设备连续体验
- 对安装门槛敏感的产品
也就是说，PWA 不是“原生替代品”这么窄。
它是 Web 应用能力上限的一部分。
PWA 最重要的不是安装，而是可靠性
这是最容易被讲偏的地方。
很多团队谈 PWA，第一反应是：
- 能不能加到桌面
- 能不能出安装弹窗
这些当然重要。
但如果只看安装，你会把真正的主干价值看丢。
PWA 首先是一个可靠性话题。
因为一个应用如果：
- 网络差就崩
- 资源一丢就白屏
- 用户返回时状态全没
- 慢网环境体验极差
那即使用户把它“装”到桌面，也不会觉得它是一个好产品。
所以更成熟的表述应该是：
PWA 的地基是可靠性，安装只是更高一层的产品表达。
三个基础支柱，今天仍然成立
1. Service Worker
Service Worker 依然是 PWA 叙事里最关键的能力之一。
MDN 对它的描述很清楚：
它是一个运行在浏览器后台的脚本环境，可以拦截网络请求、管理缓存，并参与离线体验等能力。
很多文章会把它简化成“浏览器和网络之间的代理”。
这个说法便于入门。
但真正要记住的是：
Service Worker 把原本完全由浏览器直接处理的网络链路，部分变成了应用可以介入和编排的链路。
这就是它在 PWA 里的核心位置。
2. Web App Manifest
Manifest 让 Web 应用拥有一套更明确的应用级元数据。
例如：
- 名称
- 图标
- 启动地址
- 显示模式
- 主题色
它的意义不是只为了“配置安装图标”。
更深层的意义是：
它让网页在一定程度上拥有了“应用身份”。
3. HTTPS
HTTPS 不只是安全要求。
它也是能力边界。
Service Worker 等核心能力依赖安全上下文。
所以 PWA 从来不是“前端多写几个配置”。
它一开始就要求团队把安全部署作为基础前提。
Service Worker 为什么既强大又容易被误用
Service Worker 的魅力在于，它终于让前端应用对资源获取过程有了更强控制。
但问题也恰恰出在这里。
控制越强，犯错空间也越大。
很多团队第一次做 PWA，会想当然地觉得：
把所有东西缓存起来就更好。
这通常会带来一堆问题：
- 用户拿到过期内容
- 版本更新不生效
- 数据状态混乱
- 离线逻辑比原应用更难解释
所以 Service Worker 不是“有了就更先进”。
它是一个需要认真设计缓存与更新策略的能力。
生命周期为什么必须理解
很多 PWA Bug，本质上都不是 API 不会用。
而是没有真正理解 Service Worker 生命周期。
比如：
- 新版本已经部署了，为什么用户还拿旧资源
- 为什么我改了脚本但页面没更新
- 为什么两个标签页表现不一致
这些问题通常都和：
installwaitingactivate
之间的状态切换有关。
如果不理解这套状态模型，PWA 很容易在“更新体验”上出问题。
Manifest 不是装饰文件
很多项目把 manifest 当成顺手补一个 JSON。
这会低估它的产品价值。
manifest 决定的是：
用户把这个 Web 应用放进设备主屏或桌面后，它会以什么身份出现。
这会影响：
- 品牌感知
- 启动体验
- 多入口一致性
- 安装后用户对它的心理预期
所以 manifest 是产品体验的一部分。
不是只有工程作用。
安装能力要讲得克制
web.dev 对安装支持的说明非常值得记住。
今天的 PWA 安装体验并不是在所有平台、所有浏览器里都一样。
比如：
- 桌面 Safari 和 Firefox 的安装体验与 Chromium 系浏览器不同
- 移动端也会受浏览器和环境影响
- 许多 App 内浏览器并不支持正常安装流程
这意味着，一个成熟团队在讲 PWA 时，不能把“可安装”写成绝对承诺。
更准确的说法应该是：
PWA 可以提供安装能力，但实际体验高度依赖平台和浏览器支持情况。
缓存策略为什么是 PWA 的真正工程主线
PWA 的很多能力最终都会落到缓存策略上。
因为所谓“可靠”，本质上就是：
当网络环境不理想时，应用还能以怎样的方式继续工作。
这就要求团队认真区分不同资源类型。
静态资源
像：
- CSS
- JS
- 字体
- 图标
这类资源更适合稳定缓存。
动态数据
像：
- feed
- 实时数据
- 账户数据
- 订单状态
这类资源如果简单套 Cache First，就很容易把体验做坏。
所以真正成熟的 PWA 不在于“缓存得多不多”。
而在于：
缓存策略是否和数据语义相匹配。
PWA 不等于离线优先万能方案
很多资料会把 PWA 和离线画上强等号。
这也不够准确。
PWA 可以很好地支持离线和弱网能力。
但不是每个产品都需要完整离线优先架构。
有些产品只需要：
- 壳资源稳定可用
- 页面返回更快
- 关键路径不至于白屏
这已经很有价值。
所以不要把 PWA 理解成：
必须把整个应用都做成完全离线。
那是另一层复杂度。
中国互联网语境里为什么 PWA 一直有点尴尬
在中国互联网语境里，PWA 的讨论总会遇到几个现实因素：
- 超级 App 很强
- 小程序生态很强
- App 内浏览器和 WebView 很多
- 移动分发方式和海外不一样
这导致 PWA 在中国很少成为“统一主线解”。
但这不代表它没有价值。
更准确的说法是：
在中国语境里，PWA 往往不是平台级主入口能力，而更像一个在特定场景里有价值的增强型 Web 方案。
比如：
- 海外业务
- 内容和工具型产品
- 希望保留 Web 分发能力的场景
海外语境里为什么 PWA 讨论更持续
海外 Web 平台传统更强。
浏览器本身在产品分发、账号登录、跨设备使用中的位置也更稳。
所以 PWA 更容易被认真当作：
- SaaS 产品交付形态
- 跨设备体验方案
- 降低安装门槛的方法
- Web 平台能力上限的体现
这也是为什么 web.dev 这些年仍然持续更新 PWA 学习资料。
容易被讲浅的误区
误区一：PWA 就是把网页装到桌面
太浅。
PWA 的核心是可靠性、能力增强和安装能力的组合。
安装只是其中一层。
误区二：有 Service Worker 就是高级前端
不一定。
如果缓存策略和更新策略设计得很差，Service Worker 反而会放大问题。
误区三：PWA 可以替代所有原生应用
这也不准确。
平台能力、商店分发、推送能力、后台能力、系统集成深度，都仍然受环境限制。
误区四：浏览器支持差异已经不重要
恰恰相反。
PWA 最需要你正视的，就是平台差异。
成熟团队做的是：
在差异存在的情况下，把核心体验设计成仍然可靠。
面试或技术分享里怎么讲更成熟
一个更成熟的回答可以是：
PWA 不是“让网页像 App”这么简单，它本质上是通过渐进增强把 Web 应用做得更可靠、更有设备整合能力，并在支持的环境里具备安装体验。
它的核心不只是 manifest 和安装弹窗，而是 Service Worker 驱动下的缓存、更新和弱网策略。
真正的工程难点在于根据资源语义设计缓存策略，并接受不同浏览器和平台在安装与能力支持上的差异。
实践建议
实践一：做一个弱网优先的小应用
只做：
- 首页壳资源缓存
- 一个列表页
- 一个详情页
观察：
- 首次加载
- 断网返回
- 更新后资源切换
实践二：故意做错一次缓存策略
例如把动态 API 也做成 Cache First。
然后观察：
- 数据为什么旧
- 用户为什么会困惑
- 这说明资源语义和缓存策略为什么必须匹配
实践三：做一个安装支持矩阵
列出你的目标平台：
- Chrome
- Edge
- Safari
- Firefox
- iOS
- Android
- App 内浏览器
看看安装体验和能力边界哪里不同。
这会让你从“概念理解”进入真实产品判断。
工具与框架
- Workbox — Google 的 Service Worker 工具库
- Serwist — Next.js 友好的 PWA 方案
- PWABuilder — 微软的 PWA 生成器