PWA无法替代原生APP，因其受限于Web平台沙箱与API边界，缺乏蓝牙、USB、后台同步、原生AR/ML等能力，且iOS支持极弱；但可安全承接帮助中心、订单查询等轻交互模块，通过Service Worker缓存与原生桥接实现离线访问与状态共享。
HTML PWA 不能替代原生 APP，但能在特定场景下显著分担原生 APP 的压力、降低用户获取门槛，并补足离线能力与快速迭代短板。
为什么 PWA 无法取代原生 APP
PWA 本质是增强型网页，运行在 WebView 或浏览器引擎中，受限于平台沙箱和 Web API 边界。它拿不到 Bluetooth、USB、Background Fetch（部分安卓支持但 iOS 完全不支持）、Camera RAW 流、ARKit/ARCore 原生层访问权限，也无法直接调用 CoreML 或 TensorFlow Lite 进行端侧模型推理。
常见错误现象：开发者试图用 navigator.bluetooth.requestDevice() 在 iOS PWA 中连接蓝牙设备——该 API 在 Safari 中被完全禁用，连 isSupported 都返回 false。
- iOS 对 PWA 支持极其保守：不支持后台同步、无真正 Service Worker 持久化（冷启动后 SW 可能被回收）、
beforeinstallprompt事件几乎不可靠 - Android 虽开放，但不同 OEM 厂商定制系统（如华为 EMUI、小米 MIUI）会拦截
add to home screen提示或限制推送通知权限 - PWA 启动速度受网络首屏加载影响，即使有缓存，首次 install 后的冷启动仍比原生 APP 慢 300–800ms（实测 Nexus 5X + Chrome 124）
哪些原生 APP 功能可被 PWA 安全承接
适合交给 PWA 的，是那些「对性能敏感度低、依赖网络少、交互偏信息展示与轻操作」的模块。典型如：帮助中心、订单查询、活动页、客服聊天入口、商品详情页、用户资料编辑。
立即学习“前端免费学习笔记（深入）”；
从零开始创建惊艳、动画丰富且自包含的 HTML 演示文稿，或通过转换 PowerPoint 文件生成。当用户希望制作幻灯片、构建演示文稿、打造路演资料（pitch deck）、将 PPT/PPTX 转换为网页格式，或增强现有 HTML 演示文稿时，应使用此能力。该能力帮助用户通过视觉预览而非抽象选项来发掘自身审美偏好。
使用场景举例：某电商 APP 将「我的订单」页面抽离为独立 PWA，通过原生 APP 内 WebView 加载或跳转至 https://pwa.example.com/orders，复用同一套 Service Worker 缓存逻辑，用户离线时仍可查看最近 30 条订单快照。
- 必须确保 PWA 页面与原生 APP 共享同一域名（或配置
same-siteCookie 策略），否则登录态无法透传 - 原生 APP 应通过
intent://（Android）或universal link（iOS）唤起 PWA，避免用http://直跳导致 Safari 弹出“在 Safari 中打开”提示 - Service Worker 缓存策略建议用
StaleWhileRevalidate：优先返回缓存，再后台更新，避免白屏等待
// sw.js 中的关键缓存逻辑
self.addEventListener('fetch', event => {
if (event.request.url.includes('/api/orders')) {
event.respondWith(
caches.open('orders-cache').then(cache => {
return fetch(event.request).then(response => {
cache.put(event.request, response.clone());
return response;
}).catch(() => cache.match(event.request));
})
);
}
});
PWA 与原生 APP 如何共享状态和通信
核心是双向消息通道：原生 APP 主动发消息给 PWA，PWA 也可触发原生能力回调。不能依赖 window.postMessage 跨域通信（PWA 和原生不在同源），而应走平台桥接机制。
Android 示例：在 WebView 中注入 JS 接口，让 PWA 调用 AndroidBridge.showToast('已下单')；iOS 示例：用 WKScriptMessageHandler 监听 PWA 发来的 { type: 'login', token: 'xxx' } 消息。
- PWA 中检测是否运行在原生容器内：检查
typeof AndroidBridge !== 'undefined'或typeof window.webkit !== 'undefined' && typeof window.webkit.messageHandlers !== 'undefined' - 原生 APP 必须在初始化
WebView时启用setJavaScriptEnabled(true)并允许setAllowContentAccess(true)（Android）或配置WKWebViewConfiguration的userContentController（iOS） - 禁止在 PWA 中硬编码原生接口名，应通过
meta标签注入能力声明：<meta name="native-bridge" content="android:1.2.0,iOS:3.1.0">
上线前必须验证的三个兼容性断点
很多团队只测 Chrome 和最新 iOS，结果上线后大量低端安卓机白屏、iOS 用户收不到推送、华为手机无法添加到桌面——问题就出在没卡死这三个断点。
-
manifest.json的display字段必须为"standalone"或"minimal-ui"，"browser"会导致 iOS 忽略 PWA 安装提示 - Service Worker 注册路径必须为根路径（
navigator.serviceWorker.register('/sw.js')），子路径注册（如/assets/sw.js）在部分 MIUI 版本中失败且无报错 - HTTPS 是硬性前提，但自签名证书或 Let’s Encrypt 通配符证书在旧版 Android WebView（Chrome 50–60）中可能被拒绝，需用
openssl s_client -connect pwa.example.com:443 -servername pwa.example.com实测 TLS 握手是否成功
复杂点往往藏在细节里：比如 Cache-Control: no-store 响应头会让 Service Worker 彻底跳过缓存，哪怕你代码里写了 cache.put()；又比如 iOS 上 workbox-expiration 插件的 maxEntries 设为 50，实际最多只存 20 条——这是 WebKit 的内部限制，文档里根本没写。
