navigator.storage.persist() 仅承诺尽力持久化，实际仍可能被清理，因取决于用户活跃度、存储总量及浏览器策略；需先检查权限、定期保活并监控配额。
为什么 navigator.storage.persist 申请后仍被清理？
调用 navigator.storage.persist() 成功返回 true 并不保证数据永不丢失。浏览器只承诺「尽力持久化」，实际是否豁免清理，取决于用户行为、存储总量、站点活跃度及浏览器策略（如 Chrome 会定期检查「站点参与度」）。若用户长时间未访问、或该源总存储接近上限，即使已申请持久化，Cache API 或 IndexedDB 仍可能被静默清空。
必须先检查权限再调用 persist()
直接调用 navigator.storage.persist() 可能因权限未获准而静默失败（尤其在非安全上下文或 iframe 中）。务必先用 navigator.permissions.query() 确认状态：
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，且父页面允许跨域访问存储 - HTTP 环境下（非 HTTPS）该 API 不可用，
navigator.storage本身为undefined
申请后还要主动「保活」：避免被浏览器判定为闲置
Chrome 和 Edge 会基于「最近使用时间」和「交互频率」动态调整持久化资格。即使已申请成功，若站点连续 7 天无用户交互（如点击、键盘输入、fetch 请求），可能被降级为临时存储。
- 定期触发轻量级读写（例如每 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 不公开硬性配额，但单源总存储超 80% 磁盘剩余空间时，所有存储（含持久化）都可能被压缩或清理
- Firefox 对持久化存储设默认上限约 2GB，超出后写入失败并抛出
QuotaExceededError - 不要假设
quota > usage就安全——quota值可能滞后于实际可用空间，尤其在磁盘紧张时
真正关键的不是「有没有点那个按钮」，而是持续监控 storage.estimate()、响应 storage 事件，并在接近阈值时主动清理冷数据——浏览器不会替你做这个决策。
