小编Ily*_*lya的帖子

我们希望我们的网络应用可以离线使用，主要是在移动设备上。我们已经使用服务工作者为此编写了代码。应用程序数据存储在 IndexedDb 中，应用程序代码（html、js、css 等）存储在 SW 缓存中。到现在为止还挺好。我们知道用户可以删除浏览器缓存和我们的数据，这不是问题。但是浏览器本身擦除应用程序数据呢？我们还没有找到一个全面的规范，我们发现的主要信息是：

1)目前标记为“实验性”的StorageManager功能（自 2016 年起）；

2）从谷歌很短的文章在这里它（也从2016）。

代码示例如下：

if (navigator.storage && navigator.storage.persist)
  navigator.storage.persist().then(granted => {
    if (granted)
      alert("Storage will not be cleared except by explicit user action");
    else
      alert("Storage may be cleared by the UA under storage pressure.");
  });

谷歌文章说：

当本地机器上的存储空间紧张时（“在存储压力下”），用户代理会自动清除存储空间以腾出更多可用空间。当然，对于离线应用来说，这可能是不幸的，因为它们可能还没有将数据同步到服务器，或者它们可能是用户希望离线工作的应用（如音乐播放器）；所以存储规范为给定域定义了两种不同的存储模式——“尽力而为”和“持久”。当然，默认模式是“尽力而为”。“尽力而为”（又名“非持久”）域的存储可以自动清除，无需中断或询问用户。但是，不会自动清除“持久”数据。（如果系统在清除所有非持久性数据后仍处于存储压力下，

...

从 Chrome 55 开始，如果满足以下任一条件，Chrome 将自动授予持久化权限：

• 该站点已添加书签（并且用户有 5 个或更少的书签）
• 该网站具有很高的网站参与度
• 该站点已添加到主屏幕
• 该站点已启用推送通知

在所有其他情况下，该权限将被自动拒绝。

目标是确保用户可以依赖他们最喜欢的网络应用程序，而不会发现他们突然被清除了。

这是针对 Chrome 55 的，假设信息是最新的。乍一看，他们的目标听起来很合理，但是如果您仔细观察，该实现是针对“大”站点（如 Google）而不是面向任务的利基应用程序的。

确实，在 Chrome 80+ 的各种 Android 手机上测试时，持久化总是被拒绝，没有用户交互。所以，它是“尽力而为”。

我们本可以在这里停止调查并收工。毕竟，当前的手机和 PC 的存储量非常大，而我们只使用了几百 KB，所以应该没问题。问题是，我们不是：在带有 Chrome 的全新旗舰 Android …