渐进式 Web 应用 - 何时不需要 App，网站当应用就够用
渐进式 Web 应用（PWA） 是可以安装到主屏幕、几乎像原生应用一样打开，并能在离线或弱网下工作的网站。对很多业务来说，完整上架 App Store 和 Google Play 是多余的工期与预算：目录、客户后台、预约、餐厅菜单、B2B 门户，往往用基于常规 HTML、CSS 和 JavaScript 的 PWA 就能完成。下面说明何时「网站当应用」足够、哪些技术是必备，以及什么时候仍离不开原生。
- PWA - 网站 + 清单 + Service Worker：图标、全屏、缓存，有时还有推送
- 不能替代所有应用 - 重度图形、深层设备访问、严格的 App Store SLA 仍属原生
- 一套代码 - 起步用一个 Web 版本，而不是分开的 iOS/Android 团队
- 无需商店更新 - 部署到服务器：用户下次访问即获得新版本
- SEO 仍在 - 仍是搜索中的页面，不是封闭二进制
- 起步清单 - HTTPS、
manifest.webmanifest、Service Worker、响应式与较快的 First Contentful Paint
用白话解释什么是 PWA
PWA（Progressive Web App）是一组实践与 Web API，让网站表现得像已安装的应用：
- 可安装 - 从浏览器装到手机或桌面（图标、独立窗口，没有常规范址栏）。
- 打开快 - 依靠缓存的 shell（界面外壳）。
- 扛得住弱网 - 显示已缓存页面，或把操作排入「稍后发送」队列。
- 看起来像原生 - 启动画面、theme-color、
display: standalone。
它不是另一种语言，也不是「又一个框架」。它是你现有的网站，达到可安装标准并可靠交付内容。Chrome、Edge、Safari、Firefox 对基础场景已经成熟；推送、后台同步与部分设备 API 仍有差异。
何时「网站当应用」就够用
当产品本质是浏览器里的数据界面，而不是游戏或系统工具时，PWA 划算。
合适候选：
| 场景 | 为什么 PWA 通常够用 |
|---|---|
| 目录、菜单、价目、预约 | 内容 + 表单；应用商店增值有限 |
| 客户中心 / B2B 门户 | 登录、表格、文档、订单状态 |
| 员工内部工具 | 装到工作手机即可，无需商店上架 |
| 媒体与信息流（新闻、博客、文档） | SEO 与链接分享很重要 |
| 在推广「正统 App」前的 MVP | 用不了两支原生团队的成本验证需求 |
若用户每周多次回访，想要「像银行那样」的图标，并在地铁无网时仍有稳定体验 - PWA 能满足预期，且无需 App Store 审核。
何时更适合原生应用
诚实判断胜过「PWA 取代一切」的营销：
- 需要严格后台任务、复杂 Bluetooth / NFC / 底层传感器；
- 3D/AR 性能、重度摄像与离线游戏至关重要；
- 产品必须只活在商店里（合作伙伴橱窗、要求原生的企业 MDM）；
- 需要以 Apple/Google IAP 作为主要变现；
- 团队已有强大的 iOS/Android 编制，Web 只是次要渠道。
2026 常见折中：对所有人提供 PWA 或响应式网站 + 仅在指标证明需求处做原生（留存、移动流量占比、重复访问）。
PWA 由什么组成
没有这些就谈不上「渐进」：
1. HTTPS
Service Worker 与可安装性要求安全源。本地 localhost 是开发例外。
2. Web App Manifest
manifest.webmanifest（或 JSON）描述名称、图标（通常 192 与 512）、start_url、display、主题色。没有它，浏览器不会提示「安装应用」。
3. Service Worker
后台脚本：缓存 shell 与静态资源，提供离线回退，网络中断时有时会排队 POST。常见策略：CSS/JS/图标用 cache-first，API 与价格用 network-first。
4. 响应式且够快的 UI
PWA 救不了慢站。需要响应式、图片压缩与合理的 JavaScript 包体积。否则「应用」装一次就会被删。
5. 可选：推送、Share Target、快捷方式
推送与角标能提升留存，但会增加同意与通知策略复杂度。清单中的 shortcuts 可在长按图标时提供快捷操作。
商业效果：不带幻觉的数字
比的是预算与发布周期，不是「潮不潮」。
| 参数 | PWA / 网站 | 原生应用 |
|---|---|---|
| MVP 周期 | 以周计 | 双端常常以月计 |
| 更新 | 部署到服务器 | 商店审核 + 等用户更新 |
| 分发 | URL + 「添加到主屏幕」 | 商店、ASO、审核 |
| 搜索与链接 | 完整 SEO | 有限；流量常来自商店与广告 |
| 维护成本 | 一个前端 | 两套代码或跨端 + 仍要 Web |
在验证阶段，以及内容与表单比硬件访问更重要的服务上，节省是真实的。若承诺「完整原生银行体验 + 复杂生物识别 + 后台地理触发」- 省下来的钱就没了，更适合原生。
在现有站点上落地的清单
- 先把基础速度与响应式做好 - 否则 PWA 只会固化糟糕体验。
- 发布清单与图标集（必要时支持浅色/深色）。
- 注册 Service Worker，缓存策略要清晰；个人信息不要无过期缓存。
- 在 Chrome DevTools / Lighthouse 检查可安装性（PWA 类别）。
- 测试 Safari（iOS） - 通过「添加到主屏幕」安装；推送与部分 API 与 Android 不同。
- 统计安装量 以及「从图标打开」vs「从链接进入」。
- 不要破坏收录 - 内容仍应作为普通 URL 可用；PWA 是增强层，不是没有 SSR/预渲染的 SPA 死胡同。
- 诚实描述离线能力 - 无网时哪些可用、哪些不可用。
在建站平台上能力因产品而异：有的一键开启 PWA，有的需要自有托管与自定义代码。原则相同 - 清单 + Worker + HTTPS。
常见错误
- 把没有 Service Worker 与清单的任何响应式站点都叫作 PWA。
- 把价格与库存 API「永久」缓存 - 用户看到昨天的价目。
- 承诺「像 App Store 一样」却砍掉 UX 与性能预算。
- 忽略 iOS：只测 Android Chrome。
- 做沉重 SPA 且不索引，丢掉搜索流量。
- 首次访问就强推通知 - 用户屏蔽通知与品牌。
总结
渐进式 Web 应用适合你需要「主屏幕图标 + 快速回访」，而不是双端完整原生产品时。对目录、门户、预约与内部工具，「网站当应用」往往就够。对游戏、深层硬件与以商店为中心的变现 - 请规划原生。从 HTTPS、清单、Service Worker 与速度开始；其余按留存指标迭代，而不是跟风。
常见问题
PWA 与普通移动网站有何不同？
普通响应式网站在浏览器标签里打开。PWA 增加可安装性（图标、独立窗口）、用于缓存与离线的 Service Worker，以及带应用元数据的清单。外观可以是同一套设计，但交付与回访模型更接近应用。
能否把 PWA 上架 App Store 和 Google Play？
Google Play 对 Trusted Web Activity / PWA 包装相对友好。App Store 更严：没有明确原生价值的「套壳网站」常被拒。对多数业务，PWA 主渠道是浏览器与「添加到主屏幕」；商店是另一套产品、另一套要求。
PWA 能完全离线吗？
很少能完全。 通常离线可用的是 shell、已打开过的页面与静态资源。实时价格、账户与支付需要网络。好的 PWA 会诚实标明不可用部分，并在需要时把操作排队到恢复联网。
PWA 需要单独域名或子域名吗？
单独域名不是必须。更重要的是稳定 origin（协议 + 主机 + 端口）、正确的 start_url，以及 Service Worker 更新不与旧缓存冲突。有时会放到 app.example.com，那是组织选择，不是规范要求。
站点已在 WordPress、Tilda 或自有栈上，从哪开始？
先看平台是否自带清单与 Service Worker。若无 - 加上静态清单、最小 shell Worker 与图标；自有栈上通常一个冲刺即可。然后测量 Core Web Vitals，在 Android 与 iOS 测安装，并定好 API 缓存策略。不要先做推送：先做到安装快、再次打开稳定。