Navigator.storage.persist申请持久化配额防自动清理

在Web开发中，浏览器存储常用于缓存资源或保存用户数据。开发者通常知道，调用 navigator.storage.persist() 可以向浏览器申请“持久化”存储，以避免数据被自动清理。然而实际情况更为复杂：即使申请成功，数据仍有可能丢失。这背后的原因是什么？我们又该如何确保数据真正持久保存？

为什么申请了持久化，数据仍然会丢失？

一个常见的误解是，认为 navigator.storage.persist() 返回 true 就意味着数据获得了永久保存的保障。实际上，浏览器的承诺是“尽力而为”。数据是否会被清理，取决于一套复杂的综合评估机制：用户有多久没有访问你的站点？整个源占用了多少存储空间？浏览器的内部策略是什么？

以Chrome浏览器为例，它会定期评估“站点参与度”。如果用户长时间未与站点交互，或者网站占用的总存储量接近某个阈值，那么即使是被标记为“持久化”的 Cache API 或 IndexedDB 数据，也可能被静默清理。因此，成功调用只是第一步，并非终点。

第一步：先检查权限，再发起申请

直接调用 persist() 可能会静默失败，尤其是在非HTTPS环境或某些受限的 iframe 中。更稳妥的做法是，先使用权限查询API进行探测：

if ('permissions' in navigator) {
  const result = await navigator.permissions.query({ name: 'persistent-storage' });
  if (result.state === 'granted') {
    const persisted = await navigator.storage.persist();
    console.log('持久化已启用:', persisted); // true 表示当前已持久化
  } else if (result.state === 'prompt') {
    // 用户尚未决定，调用 persist() 会触发弹窗
    const persisted = await navigator.storage.persist();
  }
}

这里有几点需要注意：

• result.state 有三种状态：'granted'（已授权）、'denied'（已拒绝）或 'prompt'（待询问）。不能仅依赖 persist() 的返回值来判断最终状态。
• 在 iframe 中使用时，必须确保其 sandbox 属性包含 allow-scripts，并且父页面允许跨域存储访问。
• 最关键的一点是：此API仅在安全的HTTPS上下文中可用。在HTTP环境下，navigator.storage 对象本身可能为 undefined。

第二步：持续“保活”，避免被判定为闲置站点

申请成功并不意味着可以高枕无忧。像Chrome和Edge这类浏览器，会动态评估站点的“活跃度”。如果用户连续多天（例如7天）没有与你的站点产生任何交互——包括点击、输入，甚至是前端发起的网络请求——那么你的“持久化”资格就可能被降级，存储空间会被重新标记为可清理的临时存储。

因此，主动的“保活”策略至关重要：

• 定期触发轻量级读写：可以设置一个间隔（例如每48小时），向 IndexedDB 写入或更新一个时间戳记录。这个简单的操作能有效刷新站点的活跃信号。
• 谨慎依赖后台任务：不要完全依赖 Service Worker 的定时同步或后台任务来保活。当前台页面不存在时，这些任务可能被浏览器节流甚至跳过，无法提供可靠的活跃度证明。
• 利用页面可见性事件：在 visibilitychange 事件监听中，当检测到页面从后台变为前台时，立即执行一次小体积的存储操作（例如用 cache.match() 查询一个资源，或用 IDBKeyRange.bound() 进行一次简单的索引查询），这能向浏览器明确传达“用户回来了”的信号。

第三步：认清配额限制，持久化不等于无限空间

另一个核心认知是：navigator.storage.persist() 改变的是数据被清理的“优先级”，而不是提供一个无限大的存储空间。实际可用空间仍然受限于浏览器配额。要了解当前状况，必须查询 navigator.storage.estimate()：

const { usage, quota } = await navigator.storage.estimate();
console.log(`已用 ${usage} / 总配额 ${quota}`); // quota 在 Chrome 中常为 0（表示「尽力而为」），Firefox 则可能返回具体字节数

不同浏览器的策略差异显著：

• Chrome：通常不公开一个硬性的配额上限（quota 常显示为0，意为“尽力分配”）。但当单个源占用的存储超过磁盘剩余空间的80%时，所有存储，包括已持久化的部分，都可能面临压缩或清理。
• Firefox：对持久化存储设有相对明确的默认上限（大约2GB）。一旦超出，写入操作会直接抛出 QuotaExceededError 错误。
• 通用陷阱：即使 quota 显示的值远大于 usage，也不代表绝对安全。quota 的更新可能存在滞后，尤其是在磁盘空间突然紧张的情况下。

因此，真正的关键不在于“是否点击了申请按钮”，而在于建立一套持续的监控和响应机制。需要定期检查 storage.estimate()，监听 storage 事件，并在存储使用量接近阈值时，主动清理那些不常用的“冷数据”。浏览器不会自动为你做出这些优化决策。