有些网站打开以后，浏览器会提示“安装此应用”。点完桌面多了图标，启动还有独立窗口，甚至断网时也能打开一部分内容。明明刚才还是网页，怎么突然开始兼职 App 了？
这类网站通常就是 PWA，完整名称是 Progressive Web App，也就是渐进式 Web 应用。
PWA 底层仍然是 Web
普通网页通常是浏览器请求服务器，拿到 HTML、CSS 和 JavaScript 后渲染页面。PWA 没有抛弃这一套，而是在它上面增加一些浏览器和操作系统能够识别的能力。
第一个关键：Web App Manifest
PWA 通常会提供 Manifest，告诉系统应用名称、图标、启动地址、主题色、显示方式和屏幕方向。浏览器读到这些信息后，才有条件把网站以更像应用的方式放到桌面或主屏幕。
安装 PWA 通常并不等于下载一个完整 APK。系统更多是在保存站点入口、图标、Manifest 信息和相关浏览器状态，真正渲染页面的仍然是浏览器内核。
第二个关键：Service Worker
Service Worker 是 PWA 最重要也最容易制造玄学 Bug 的组件之一。它运行在网页和网络之间，可以决定某个请求走网络，还是直接从 Cache Storage 返回。
这让 PWA 能做到快速启动、离线页面和预缓存资源，但缓存策略写错以后，也会出现“服务器已经新版，手机还活在旧版”的情况。
如果正好遇到这种问题，可以继续看 Lab 的网页已经更新但看到的还是旧版本。
离线不等于整个互联网都离线可用
PWA 只能离线使用开发者提前缓存或本地保存的内容。账号余额、云文件、实时聊天等需要服务器的数据不会凭空出现。所谓离线能力，本质上是“已经准备好的部分还能继续工作”。
PWA 和原生 App 的边界
原生 Android/iOS App 能更直接地调用系统能力，而 PWA 依赖浏览器开放的 Web API。PWA 的优势是同一套 Web 代码能覆盖电脑、Android、iPhone 和平板，发布更新也不一定需要重新走应用商店。
但大型 3D 游戏、深度后台服务、高性能媒体处理、某些硬件接口等场景，原生 App 依旧更合适。
为什么不同手机表现会不一样
Android Chromium、iOS Safari 和其他浏览器对 PWA API、后台生命周期、文件和分享能力的实现并不完全相同。所以“在 Android Chrome 正常”不代表 iPhone 上百分百一模一样。
PWA 为什么能接收系统分享
Manifest 可以声明 Web Share Target。安装后，系统分享文件或文本时，PWA 可能出现在“用其他应用打开”或分享面板里。背后链路可能包括 Android Intent、浏览器、Service Worker 和页面代码，任何一层处理不当都可能导致启动画面卡住、文件没送进页面或内存暴涨。
大文件为什么特别容易出问题
浏览器处理文件时常见 Blob、ArrayBuffer、ReadableStream 和 Base64。如果几百 MB 的文件被完整读入内存、复制几遍、再转 Base64，实际内存占用可能远超原文件。移动设备尤其容易卡顿甚至被系统杀掉。
因此大文件处理更适合流式读取、分片、减少复制，并尽量避免不必要的 Base64 中间态。
安装 PWA 会自动拿到所有权限吗
不会。摄像头、麦克风、通知、定位、文件等权限仍然受浏览器和系统授权控制。安装只是让网站拥有更像 App 的入口和生命周期，不是给它发一张“手机随便逛”的通行证。
一个真实的功能型 PWA 例子
Wenvo Tools 本身就是适合 PWA 的工具站：
它本质上仍然是网站，但在支持的设备和浏览器上可以安装，并承担分享、转换、检测等更接近应用的工作。这类“打开就用，需要时再安装”的工具站，正是 PWA 很擅长的场景。