企业渐进式 Web 应用（PWA）：安装、离线模式、通知，以及何时优于原生应用

许多企业希望出现在客户的手机上，但问题总是一样：是否必须为 Android 和 iPhone 开发原生应用，并承担随之而来的成本、时间和应用商店审核流程？有一个常被忽视的中间选项：渐进式 Web 应用，即 PWA。PWA 是用特定技术构建的网站，行为像应用：可以安装到主屏幕，以无地址栏的全屏窗口打开，在网络不佳时仍能部分工作，并在特定条件下发送通知。

本文用企业主能听懂的语言解释 PWA 是什么、能做什么与不能做什么、使其运转的技术组件、何时 PWA 相比原生应用已经足够，以及在安全、成本和度量方面需要注意什么。内容是决策框架，而不是对特定结果的承诺，因为 PWA 是否合适在很大程度上取决于您产品的需求。

摘要

• PWA 是可安装、可在无网络时部分工作的网站，一套代码库服务所有设备
• 三个核心组件：应用清单、Service Worker 和 HTTPS
• 适合内容型应用、表单、目录、客户门户和内部工具；不太适合深度硬件需求
• 功能支持因浏览器和操作系统而异，尤其是 iPhone 上的通知和安装，因此需要在真实设备上测试
• 缓存与更新策略决定用户拿到的是最新版本还是卡在旧版本
• 从一个高价值工作流起步，衡量使用情况，再决定是否需要原生应用

什么是 PWA

PWA 不是某个特定的产品或框架，而是一组现代浏览器能力与良好设计实践的结合。网站满足以下若干特征时，就称为 PWA：

• **可安装**：用户可以将其添加到主屏幕或应用菜单，并在独立窗口中打开
• **可靠**：即使网络缓慢或断开，页面和关键数据仍能显示
• **快速**：加载迅速，触摸响应无延迟
• **集成**：可使用部分设备能力，如相机、定位、分享，以及在特定条件下的通知
• **安全**：通过 HTTPS 提供
• **可被发现**：因为仍是网站，可被搜索引擎索引并通过链接分享

与原生应用的重要区别：PWA 通过 URL 访问，不必经过应用商店，一套代码可在所有设备上运行。用户只需打开链接，无需先下载大型安装包。对企业而言，这减少了客户旅程起点的阻力。

三个核心技术组件

您不必亲自写代码，但了解这些组件有助于评估技术团队或供应商的方案。

1. 应用清单

一个向设备描述应用的小文件：名称、多种尺寸的图标、主题色、起始页面和显示模式（例如全屏）。正是它让浏览器能够提供“安装应用”选项，并在主屏幕上显示正确的图标。高质量的图标和清晰的名称，能给人与手机上其他应用同样的专业印象。

2. Service Worker

一个在后台运行、位于应用与网络之间的脚本。它可以拦截请求，并决定从网络、设备缓存还是两者混合获取。Service Worker 是离线模式、后续访问快速加载以及接收推送通知背后的引擎。由于它很强大，也需要谨慎管理：Service Worker 的错误可能让用户卡在旧版本。

3. HTTPS

PWA 要求安全连接。除了技术要求之外，它还能保护用户数据，并防止第三方向您的应用注入内容。

离线模式：现实的预期

离线功能往往是选择 PWA 的主要原因，但预期需要现实。离线并不意味着所有功能在无网络时都能工作。可根据需求选择几个级别：

• **兜底页面**：离线时显示友好的页面，说明情况并展示已打开过的内容，而不是浏览器的错误信息
• **访问过的内容仍可用**：打开过的文章、目录或票券可以重新阅读
• **操作延迟并稍后同步**：用户离线时填写表单或记录数据，网络恢复后自动发送
• **完整的离线优先**：主要数据保存在本地并双向同步。这是最复杂的，因为必须处理两台设备修改同一数据时的冲突

适合部分离线的真实例子：在弱信号地区记录拜访的外勤销售应用、巡检清单、调查表单或活动宾客名单。如果您需要完全不怕断网的收银交易，请学习离线优先收银与多设备同步中的模式，因为那里的数据冲突和同步队列问题同样适用于 PWA。

要小心设备上的敏感数据。本地存储的数据在设备丢失或被借用时可能被访问。仅存储必要内容，退出登录时删除，并考虑加密或为本地数据设置有效期。

推送通知：能力与限制

通知可以提高参与度，例如预约提醒、订单状态或库存更新。但有几点限制需要从一开始就了解：

• 用户必须明确授权。第一个页面打开时立刻请求授权通常会被拒绝；应在相关时刻、用户看到好处之后再请求
• 各平台的支持不同。在 Apple 设备上，PWA 的通知通常要求应用已添加到主屏幕，且其行为可能随系统版本变化。务必查看最新文档并在真实设备上测试
• 过多通知会让用户关闭通知或删除应用。发送有用、有计划且偏好可调的内容
• 对于验证码或付款确认等重要消息，请提供电子邮件或短信等备用渠道，因为推送通知不保证送达。消息渠道见[WhatsApp Business 客户服务集成](/blog/integrasi-whatsapp-business-untuk-layanan-pelanggan)

PWA 还是原生应用：如何选择

没有通用答案。请考虑以下维度。

PWA 通常足够的情形

• 您的产品是内容、目录、表单、门户或看板
• 您需要快速触达用户，而不受下载和应用商店更新的阻碍
• 预算和团队有限，希望网页和移动端共用一套代码库
• 应用供员工在各种设备上内部使用
• SEO 和便于分享链接对增长很重要

原生应用更合适的情形

• 您需要深度访问硬件或系统，如高级蓝牙、特殊传感器、繁重的后台处理，或特定的数字钱包集成
• 需要高图形性能，例如游戏或视频编辑
• 应用商店中的存在是获客或信任策略的一部分
• 您需要浏览器尚不支持的操作系统功能
• 极具平台特色的体验是产品的差异化优势

两者之间的选项

跨平台框架用一套代码提供两个系统的原生应用，并可与网站结合使用。比较见选择移动应用技术：Flutter、React Native 还是原生和网页应用、移动应用还是两者兼有。对许多企业而言，合理的策略是：先用 PWA 验证需求，若使用数据证明有必要，再增加原生应用。

缓存与更新策略

这一部分常常是问题的来源。Service Worker 把文件存在设备上，所以更新不会自动显示。需要考虑：

• **用版本缓存静态资源**：每次发布名称都会改变的文件，替换起来很容易
• **按内容类型选择策略**：必须新鲜的数据优先走网络，很少变化的资源优先走缓存，一般内容则先显示缓存同时在后台更新
• **更新通知**：有新版本时告知用户并提供重新加载，不要让他们在旧版本上停留数日
• **应急出口**：提供取消有问题的 Service Worker 的办法，例如终止开关文件，使发布失误不会困住用户
• **最低版本**：对于变化的 API，用友好的提示拒绝过旧的应用版本

与此互补的服务器端和 CDN 缓存原则见缓存与 CDN：加速企业网站和应用。为实现安全发布，请结合功能开关与分阶段发布，使重大变更可以回滚。

性能与用户体验

缓慢的 PWA 不会被安装或再次使用。请注意：

• 脚本和图片的大小，以及分阶段加载以使首页快速显示
• 真实体验指标，如[核心网页指标：LCP、INP、CLS](/blog/core-web-vitals-lcp-inp-cls-panduan-untuk-website-bisnis)中所述
• 足够大的触控目标、响应式布局，并且不依赖悬停
• 与您的设计系统一致的设计，如[业务应用的设计系统与界面一致性](/blog/sistem-desain-dan-konsistensi-antarmuka-aplikasi-bisnis)
• 可访问性：颜色对比度、文字大小和读屏器支持
• 离线、缓慢或失败时有清晰的表现，而不是空白屏幕

安全与隐私

由于 PWA 是 Web 应用，网络安全实践同样适用，另外还有一些特别之处：

• 使用 HTTPS 和适当的安全头
• 限制 Service Worker 的作用范围，避免把敏感令牌存放在其他脚本容易读取的位置
• 采用强认证和合理的会话有效期，尤其是共用设备
• 不要在设备缓存中存储过多个人数据
• 用限速保护 API 免遭滥用，如[业务 API 设计](/blog/desain-api-bisnis-versioning-dokumentasi-dan-batas-laju)所述
• 仅在需要时请求设备权限（定位、相机、通知）并说明原因
• 遵守适用的个人数据保护规定，包括同意以及用户对其数据的权利

关于 Web 端对自动化流量的防护，请参阅防范机器人、爬取和自动化攻击。

成本与时间

PWA 通常比两个原生应用更经济，因为一套代码库服务所有设备，更新无需在应用商店排队审核即可上线。但成本仍存在于若干部分：

• 设计良好的移动体验，而不是简单地缩小桌面视图
• 开发 Service Worker、缓存策略和离线同步
• 在各种设备和浏览器上测试
• 推送通知，如果需要发送服务和偏好管理
• 持续维护，因为浏览器行为在不断演进

要有纪律地确定第一版的范围。一个打磨好的工作流，例如下单或工单跟踪，比许多半成品功能更有用。项目定价模式及合同结构见软件项目定价模式。

用例示例

以下是常适合做成 PWA 的应用类型，不涉及特定客户或数据：

• **客户门户**：查看订单、发票和服务状态，并在变化时收到通知
• **外勤团队应用**：在弱信号地区记录拜访、照片和表单，联网后同步
• **目录与订货**：希望合作伙伴用手机下单而无需下载大型应用的商店或经销商
• **活动票券与签到**：即使信号拥挤也能打开的电子票，可与[活动管理与在线票务系统](/blog/sistem-manajemen-event-dan-tiket-online-pendaftaran-pembayaran-dan-validasi)结合
• **内部工具**：员工在各种设备上使用的审批、考勤或检查清单
• **服务预订**：日程和提醒，与[在线预订与预约系统](/blog/sistem-booking-dan-reservasi-online-untuk-bisnis-jasa)相配合

衡量成功

在构建之前设定衡量标准，使后续决策基于数据：

• 安装 PWA 的用户数，以及安装后回访的用户数
• 主要流程（如下单或填写表单）的完成情况，与普通网页版对比
• 用户设备上的真实加载速度和错误率
• 通知授权率与关闭率，及其对期望行为的影响
• 离线使用情况与同步成功率
• 与应用相关的用户反馈和支持工单

用这些结果判断 PWA 是否已足够，还是该增加原生应用了。数据支持的决定比追随潮流的决定更便宜。

常见错误

• 认为 PWA 在所有设备上自动拥有与原生应用相同的能力
• 没有在 iPhone 以及开发团队所用浏览器之外的浏览器上测试
• 过早且过于频繁地请求通知权限
• 在设备上存储敏感数据却没有删除政策
• 没有提供更新机制和取消 Service Worker 的办法
• 做出半成品的离线模式，显示过期数据却没有任何标记
• 忽视 SEO 和可分享性，而这正是 Web 的主要优势

常见问题

PWA 可以通过应用商店安装吗？

在某些平台上，PWA 可以被封装并通过商店分发，但各商店规则不同且可能变化。许多企业只依赖从浏览器直接安装。请查看目标商店的最新政策。

PWA 能在 iPhone 上运行吗？

许多核心功能可以运行，但通知、安装和本地存储等某些功能的支持与 Android 不同，且可能随系统版本变化。在向客户承诺功能之前，请在真实设备上测试并阅读最新文档。

PWA 会影响 SEO 吗？

PWA 仍是网站，因此其公开页面可以被索引。请确保重要内容正确渲染、URL 简洁且速度良好。Service Worker 并不能取代基本的 SEO 实践。

构建 PWA 需要多久？

取决于范围。把现有网站改造成可安装并具备基本离线能力相对较快，而具有完整离线同步和通知的应用则需要更长的规划。先从一个主要流程开始。

PWA 中的用户数据安全吗？

在落实网络安全实践并限制本地数据的前提下是安全的。最大的风险通常在于存储在设备上的数据和未受管理的会话。请采用强认证、加密连接和删除政策。

PWA 可以连接 ERP 或 POS 系统吗？

可以，通过 API。PWA 充当核心系统的轻量界面，因此整洁的 API 设计至关重要。这是客户门户和外勤应用的常见模式。

结论

PWA 提供了一条实用的中间道路：以网站的成本和发布速度获得类似应用的体验。对于不需要深度硬件访问的门户、表单、目录和工作工具，它的价值最大。关键在于对离线和通知抱有现实的预期、在真实设备上测试，以及整洁的更新策略。从一个高价值流程起步，衡量结果，再根据数据决定下一步。