电商做 PWA：它改变什么、不改变什么，以及怎么落地

电商为什么一直绕回 PWA

在线商店有一个内容站不存在的结构性矛盾：购买意愿最高的那一刻，几乎从来不是用户愿意安装东西的那一刻。在「加入购物车」和「去支付」之间插一个 App 安装引导，订单就没了；等付完款再引导，你又在跟收据邮件抢注意力。

渐进式 Web 应用（PWA）绕开了这个取舍。它就是你的店铺本身——同一个网址、同一份商品目录、同一个结算流程——只是在上面加了 service worker、web app manifest 和 HTTPS 三样东西。这三样让店铺可以被添加到桌面、以无浏览器边框的全屏方式启动、为回访做缓存，并且（在 Android 上）通过推送做二次触达。首次访问的体验一点没变：用户依旧点开链接就能直接下单。

PWA 对店铺具体改变了什么

安装引导从「购买前」挪到了「购买后」。 已经完成一次下单的用户，才有留下这个图标的理由。在这个时点提示，转化率远高于在商品页弹插屏；即使用户拒绝，你也什么都没损失——店铺还是那个网站。

回访速度变快，而速度是一个转化变量。 service worker 可以缓存应用外壳、分类页模板、商品图和静态资源。回访时布局直接从缓存渲染，只有价格、库存和个性化内容走网络。在新兴市场占主导的中低端 Android 机型上，这个差别就是「跳出」和「继续逛」的分界线。

Android 的二次触达不再只有邮件。 Web Push 在 Android 上触达已安装的 PWA，方式和原生 App 一样——到货提醒、降价通知、弃购挽回——而且不需要过应用商店审核。iOS 只对用户手动「添加到主屏幕」的 PWA 开放 Web Push，所以把它当成 Android 优先的渠道，并为 iOS 准备邮件或短信兜底。权限弹窗的具体机制见 PWA 在 Android 上的推送通知。

分发不再卡在审核队列上。 不用提交、不用灰度、改个价格不用等政策裁决。对于商店政策收紧的品类、或者审核周期不可预测的场景，这一点常常是决定性因素而不是加分项——完整对比见 PWA 与 APK 的取舍。

买量流量落到它承诺的那个页面。 广告点击直接打开商品页，中间没有商店列表页、没有安装步骤、没有冷启动引导。这也是同一套素材在 PWA 上通常呈现出明显更短的「首次购买路径」的原因。

PWA 解决不了什么

这一节写准确，能省掉一个季度的无效投入。

• 它本身不是增长渠道。 PWA 改变的是店铺的交付方式，不是有没有人想买你的东西。流量还是得从搜索、买量或社媒来。
• iOS 依然是受限平台。 加到主屏可用，装完之后 Web Push 也可用，但引导是手动的（分享 → 添加到主屏幕），没有浏览器主动弹的安装横幅，后台能力也更窄。要预期 iOS 安装率更低，并按这个前提设计。
• 深度依赖硬件的功能仍属原生。 蓝牙外设、后台定位、高级相机控制、平台级生物识别 API 在 Web 上要么没有要么残缺。绝大多数店铺根本用不到；如果你确实要用，那是真实约束，不是偏好问题。
• 失去应用商店的自然发现。 你用商店列表位换了开放网页。对多数电商这是划算的——获客本来就以搜索和买量为主——但它确实是一次交换。
• SEO 需要专门做。 单页架构的店铺可能对人渲染得很漂亮、对爬虫却近乎空白。商品页和分类页需要服务端渲染或预渲染的 HTML、真实 URL 和 canonical 标签。踩坑清单见 PWA 的 SEO 难点。

可落地的实施顺序

1. 先把 manifest 写对。 name、short_name、start_url、display: standalone、theme_color、background_color，以及 192px 和 512px 图标（含一张 maskable）。这里写错，安装提示根本不会出现——浏览器只是默默不提供，不会给你任何显眼的报错。完整字段清单见 PWA manifest 必填项。

2. 全站 HTTPS。 否则 service worker 直接拒绝注册。有些浏览器里，一张混合内容的图片就足以让注册失败。

3. 按内容类型分别设缓存策略，不要一刀切。 静态外壳和资源：cache-first，缓存名带版本号。商品详情和分类数据：network-first，缓存兜底。价格、库存、购物车、结算：永远 network-only。 把价格从缓存里发出去不是性能优化，是价格事故。

4. 结算流程绝对不缓存。 支付页、订单确认页，以及它们背后的会话接口，一律不缓存、只在线可用。这是通用「全都缓存」型 service worker 模板最容易违反的一条——支付层怎么接见 PWA 的支付接入。

5. 老实设计离线态。 离线浏览「之前看过的商品」是真有用；离线结算不是——让用户以为下单成功、实际只是排进了队列，比一句「当前离线，购物车不会丢」糟糕得多。

6. 缓存要带版本、要清理。 每次发版换一个缓存名，并在 activate 事件里删掉旧缓存。发版后「页面外壳还是老的」这类 bug，几乎全是这一条没做。

怎么衡量它是否奏效

这些埋点要在上线前就做好，而不是事后补：

把「安装 → 首次复购」和「安装数」分开看。一个从不产生第二次会话的安装，是虚荣指标。

这家店该不该做 PWA

通常该做：移动端网页已占流量大头；买量直接投商品页；复购是重要指标；商品是可浏览型而非硬件强绑定；应用商店审核周期或政策是现实风险。

通常不该做：购物体验确实依赖原生硬件能力；应用商店的自然发现在该品类是真实获客渠道；或者用户几乎全是 iOS，而项目的全部意义就在二次触达。

对于要把 Web 店铺规模化投放到 Android 用户的团队，ROIBest 负责交付层——manifest 与 service worker 配置、安装引导行为、推送链路——让你的精力留在商品和漏斗上，而不是消耗在这些管道上。如果你还在纠结打包形态本身，可以先看不写代码把网站变成应用。