在多源网站中构建渐进式 Web 应用所面临的挑战和解决方法。
背景
过去，使用多源架构具有一些优势，但对于渐进式 Web 应用来说，这种方法带来了许多挑战。具体而言，同源政策对共享 Service Worker 和缓存等内容、权限以及跨多个源实现独立体验施加了限制。本文将说明使用多个源的好与坏，并说明在多源网站中构建渐进式 Web 应用所面临的挑战和解决方法。
使用多个来源的好与坏
网站采用多源架构是有正当理由的，这主要是为了提供一组独立的 Web 应用或打造彼此完全隔离的体验。此外，还有一些应用场景是应避免的。
良好
我们先来看看这些实用的原因：
本地化/语言：使用国家/地区代码顶级域名来划分在不同国家/地区提供的网站（例如
https://www.google.com.ar），或使用子域名划分定位到不同地理位置的网站（例如：https://newyork.craigslist.org）或针对特定语言（例如https://en.wikipedia.org）提供内容。独立的 Web 应用：使用不同的子网域提供用途与主要来源网站截然不同的体验。例如，在新闻网站上，填字游戏 Web 应用可能会有意通过
https://crosswords.example.com提供，并作为独立的 PWA 安装和使用，而无需与主网站共享任何资源或功能。
不好
如果不采取上述任何行动，在构建渐进式 Web 应用时，使用多源架构可能会不利。
尽管如此，许多网站仍出于非特定原因或因“遗留”原因而继续采用这种结构。例如，使用子网域将网站中本应属于统一体验的一部分的任意部分分开。
例如，我们强烈建议不要使用以下模式：
网站版块：将网站的不同版块划分到子网域上。在新闻网站中，首页位于
https://www.example.com，而体育版块位于https://sports.example.com，政治版块位于https://politics.example.com等位置，这种情况并不少见。如果是电子商务网站，请为商品类别使用https://category.example.com，为商品页面使用https://product.example.com等。用户流：另一种不建议使用的方法是将网站的不同部分（例如登录页或购买流程页）划分到子网域中。例如，使用
https://login.example.com和https://checkout.example.com。
对于无法迁移到单一源的情况，下面列出了一系列挑战，以及构建渐进式网页应用时可以考虑的解决方法（如果可能）。
不同源 PWA 面临的挑战和解决方法
在多个源上构建网站时，提供统一的 PWA 体验极具挑战性，主要是因为同源政策存在许多限制。我们一次看一个。
Service Worker
Service Worker 脚本网址的来源必须与调用 register() 的网页的来源相同。这意味着，举例来说，这意味着位于 https://www.example.com 的网页无法使用位于 https://section.example.com 的 Service Worker 网址调用 register()。
另一个需要考虑的问题是，Service Worker 只能控制托管在其所属的源和路径下的页面。这意味着，如果 Service Worker 托管在 https://www.example.com 上，则它只能控制来自该源的网址（根据 scope 参数中定义的路径），而无法控制其他子网域（例如 https://section.example.com 中的网页）中的任何网页。
在这种情况下，唯一的解决方法是使用多个 Service Worker（每个源一个）。
缓存
Cache 对象、indexedDB 和 localStorage 也被限制在单个源站内。这意味着无法从 https://www.section.example.com 等位置访问属于 https://www.example.com 的缓存。
在此类情况下，您可以采取以下措施来妥善管理缓存：
利用浏览器缓存：始终建议使用传统的浏览器缓存最佳做法。此技术还具有跨源重复使用已缓存资源的额外优势，这是通过 Service Worker 的缓存无法实现的。如需了解有关如何将 HTTP 缓存与 Service Worker 结合使用的最佳实践，您可以参阅这篇博文。
确保 Service Worker 的轻量级安装：如果您要维护多个 Service Worker，请避免让用户在每次导航到新源站时都支付高昂的安装费用。换句话说：仅预缓存绝对必要的资源。
权限
权限也限定为源。这意味着，如果用户向源 https://section.example.com 授予了给定权限，相应权限将不会沿用到其他源，例如 https://www.example.com。
由于无法跨源共享权限，因此这里唯一的解决方案是针对需要特定功能（例如位置）的每个子网域请求权限。对于 Web 推送等操作，您可以维护一个 Cookie 来跟踪其他子网域中的用户是否已接受该权限，从而避免再次请求该权限。
安装
如需安装 PWA，每个来源必须拥有自己的清单，其中 start_url 相对于自身。这意味着，在指定来源（即 https://section.example.com）上收到安装提示的用户将无法在其他来源（即 https://www.example.com）上安装具有 start_url 的 PWA。换句话说，在子网域中收到安装提示的用户只能为子页面安装 PWA，而无法为应用的主网址安装 PWA。
还有这样一个问题：如果每个子网域都符合安装条件，那么同一用户在浏览网站时可能会收到多个安装提示，并提示用户安装 PWA。
为了缓解此问题，您可以确保提示仅在主源上显示。如果用户访问符合安装条件的子网域：
- 监听
beforeinstallprompt事件。 - 阻止显示提示，调用
event.preventDefault()。
这样，您可以确保该提示不会显示在网站的意外部分，而您可以继续显示，例如在主要来源（例如首页）中显示。
独立模式
在独立窗口中导航时，当用户移至 PWA 清单设置的范围之外时，浏览器的行为会有所不同。具体行为取决于浏览器版本和供应商。例如，当用户在最新版 Chrome 中退出独立模式时，系统会打开一个 Chrome 自定义标签页。
在大多数情况下，我们都没有针对这种情况的解决方法，但对于在子网域中托管的一小部分体验（例如登录工作流），您可以采用临时解决方法：
- 新网址
https://login.example.com可以在全屏 iframe 中打开。 - 在 iframe 内完成任务（例如登录流程）后，便可使用 postMessage() 将所有结果信息从 iframe 传递回父页面。
- 最后，主页面收到消息后，即可取消注册监听器，并最终从 DOM 中移除 iframe。
总结
同源政策对基于多个源构建的网站施加了许多限制，希望实现连贯的 PWA 体验。因此，为了向用户提供最佳体验，我们强烈建议您不要将网站划分为不同的来源。
对于已经以这种方式构建的现有网站，让多源 PWA 正常工作并非易事，但我们探索了一些潜在的解决方法。每种方法都各有利弊，因此请自行斟酌在网站上采用哪种方法。
在评估长期策略或网站重新设计时，请考虑迁移到单一源，除非有重要原因需要保留多源架构。
感谢各位在技术方面给出的意见和建议：Penny Mclachlan、Paul Covell、Dominick Ng、Alberto Medina、Pete LePage、Joe Medley、Cheney Tsai、Martin Schierle 和 Andre Bandarra。