📲 PWA(Progressive Web App)
一句话定性
PWA 是 Web 平台一次雄心勃勃的”夺回失地”——在原生 App 抢走移动入口之后,让网页重新拥有 App 的核心能力:离线、安装到桌面、推送通知。它在技术上完全成立,在愿景上无可指摘,却被一道它无法跨越的高墙挡住:它的成败,不取决于技术,而取决于控制着 App Store 的那两家公司是否愿意放权。
一、它是什么 & 出现的时代
PWA 不是一项技术,而是一套”能力组合”的品牌名——由 Google 工程师 Alex Russell 在 2015 年提出,把一组已有的 Web 能力打包成一个口号:让网页”渐进式”地具备原生 App 的体验。
它由几块原生能力拼成:
| 组件 | 作用 |
|---|---|
| Service Worker | 可编程网络代理 → 离线缓存、后台同步、拦截请求(整个 PWA 的引擎) |
| Web App Manifest | 一个 JSON 文件,声明图标/名称/主题色/启动方式 → 让网页可”安装”到桌面/主屏 |
| HTTPS | Service Worker 强制要求安全上下文(防中间人篡改这个强力代理) |
| Push API + Notifications | 推送通知(即使页面没打开) |
时代背景:2015 年正是移动互联网的 App 巅峰期。用户时间被原生 App 吞噬,Web 沦为”App 拉新的落地页”。PWA 是 Web 阵营的反击宣言。
二、为什么会出现(解决上一代什么痛点)
Web 在移动时代的三大"能力自卑"
相比原生 App,2015 年的网页有三个致命短板,直接把用户推向 App Store:
- 不能离线:断网即白屏。地铁、电梯、弱网下 Web 完全不可用,而 App 能打开。
- 不能安装/没有入口:网页藏在浏览器地址栏里,主屏上没有图标,用户想不起来回访。
- 不能推送:无法在用户离开后主动召回——而推送是 App 留存的命脉。
PWA 的回答简单而有力:这三件事,Web 平台原生能做到。
母题视角:又一次"框架/原生应用先跑通,平台来追认"
离线、安装、推送,这些都是原生 App 早已验证的体验。PWA 本质是 Web平台能力演进史 母题的又一次上演——平台收编”App 才有的能力”,把它变成 Web 标准。区别在于:这次平台收编的不是某个 JS 框架,而是整个原生 App 范式。胃口更大,阻力也更大。
三、核心机制 & 为什么重要
PWA 的灵魂是 Service Worker——一个独立于页面、常驻后台的脚本,充当网页与网络之间的可编程代理:
用户请求资源
│
↓
┌──────────────────┐
│ Service Worker │ ← 拦截每一个网络请求,决定:
│ (网络代理层) │ · 走缓存(离线可用)?
└──────────────────┘ · 走网络?
│ · 缓存优先 / 网络优先 / 离线兜底?
┌────┴────┐
↓ ↓
Cache Network
为什么这是质变而非量变
在 Service Worker 之前,“网页必须在线”是一条不言自明的物理假设。Service Worker 第一次让网页能完全自主决定如何响应请求——可以离线打开、可以秒开缓存、可以断网下排队待联网再提交(后台同步)。配合 Manifest 的”可安装”,网页第一次能像 App 一样脱离浏览器外壳独立存在。
(机制细节见 Service-Worker与离线能力,此处不展开。)
四、带来的新问题 / 局限
能力天花板:Web 安全模型决定了它够不到原生的深处
PWA 能做”App 的壳”,却做不了”App 的里子”:
受限能力 原因 深层硬件/系统访问 蓝牙、NFC、精确传感器、后台长驻、系统级集成等,Web 出于安全沙箱要么没有、要么残缺 后台执行受限 Service Worker 不能无限期后台运行,系统随时回收 iOS 上推送/能力长期缺位 见下节,这是最大的现实墙 调试复杂 Service Worker 的缓存与生命周期极易”卡住旧版本”,是著名的调试噩梦(详见 Service-Worker与离线能力)
五、为什么没有彻底成功 / 现状(客观)
PWA 的技术是成立的,愿景也没错,但它撞上了比技术更硬的墙——平台政治与商业模式:
三道无法用技术翻越的墙
- iOS / Apple 的消极抵抗(最关键):Web 若能绕过 App Store 直接”安装”并推送,Apple 的 30% 抽成和生态控制权就被削弱。因此 Safari 长期对 PWA 支持保守——推送通知拖到 2023 年(iOS 16.4)才在受限条件下支持,安装体验也远不如 Android。这是赤裸裸的商业模式冲突,不是技术问题。
- 没有”应用商店”这个发现入口:用户找 App 习惯去商店搜;PWA 散落在各个网址里,缺乏统一的发现与信任机制。开发者也拿不到商店的曝光与排行。
- 能力始终”差一口气”:对重度应用(游戏、专业工具),PWA 的硬件与性能上限仍不如原生,开发者权衡后往往仍选原生或跨端框架(RN/Flutter)。
现状:不是失败,而是"找到了自己的利基"
PWA 没有”颠覆原生 App”,但在特定场景里活得很好,价值真实:
- 出海 / 新兴市场:在低端机、弱网、流量贵、存储紧张的市场,“无需下载安装、秒开、占用极小” 是巨大优势。印度、东南亚、非洲的电商/资讯类应用大量采用。Twitter Lite、Starbucks PWA 是经典案例。
- 轻应用 / 工具类:不值得让用户专门下一个 App 的低频工具,PWA 的”加到主屏”恰到好处。
- 降级增强(渐进式):很多站点不做”完整 PWA”,只是借用 Service Worker 做离线缓存与性能优化——PWA 最被广泛采纳的,其实是它的”性能优化”那一面,而非”安装成 App”那一面。
一句话:PWA 没成为”Web 的 App 革命”,却成为”Web 的标配增强”——它的能力被拆开,离线/缓存这部分被普遍吸收,而”取代原生 App”的宏愿则被商业现实修剪成了一个利基场景。
六、对后续技术的影响(因果链)
移动时代:原生 App 抢走入口,Web 不能离线/安装/推送(能力自卑)
│
↓
[[Chrome|Google]] 2015 提出 PWA:把"App 能力"收编为 Web 标准
│
├──► [[Service-Worker与离线能力]] 成为引擎 ──► 终结"网页必须在线"的假设
│ │
│ └──► 离线/缓存能力被广泛吸收为"性能优化标配"(即使不做完整 PWA)
│
├──► Web App Manifest ──► "加到主屏",网页可脱离浏览器外壳
│
└──► 撞墙:iOS 保守 + 无商店入口 + 能力天花板 + 商业模式冲突
│
└──► 未颠覆原生,退守利基:出海/弱网/轻应用
│
↓
与跨端框架(RN/Flutter)、[[WebAssembly]] 一起,持续侵蚀"Web vs 原生"的边界
│
↓
指向 [[未来5到10年前端发展方向]]:Web 能力持续增强,
但"取代原生"的天花板由平台政治而非技术决定
历史地位:技术成立,败给了它控制不了的变量
PWA 是一个绝佳的反面教材——它证明了”平台能力的成败,常常不在平台自己手里”。Web Components 输给生态惯性,PWA 则输给别家平台的商业利益(Apple 不想让 Web 绕过 App Store)。它和 Web-Components 一起,共同诠释了 Web平台能力演进史 的核心命题:理念正确 + 技术可行,远不足以赢——你还得赢得它身处的那个权力与利益结构。
🔗 核心引擎:Service-Worker与离线能力 🔗 本组:Web平台能力演进史 | Web-Components | WebAssembly 🔗 同一母题:ECMAScript演进史 | ES-Modules 🔗 时代:2013-2018 SPA时代 | 2018-2023 工程化时代 🔗 浏览器/趋势:Chrome | 浏览器演进史 | 未来5到10年前端发展方向 🔗 框架:前端框架演进史 | React