IndexedDB最可能被自动清理的场景有三个：

• 设备存储剩余不足10%
• PWA安装后卸载
• 后台驻留超7天无交互

这是因为平台级资源管理机制，并非Bug。因此每次打开页面，必须按“可能为空”初始化并检查objectStore。写入后同步更新localStorage快照。

为什么会出现这种情况？因为iOS Safari和部分Android WebView将IndexedDB视为可回收的临时资源。

当设备存储紧张、用户7天未激活页面、或系统判定站点为低使用率时，会静默清空数据库且不通知开发者。

先别急着怀疑代码写错了。这其实是平台层面的一种资源管理策略。只不过它没人情味的地方在于——一声不吭就把数据给清了。

哪些场景下IndexedDB最可能被自动清理

设备存储空间是关键因素。如果系统存储已用超过90%，IndexedDB被清空的概率超过九成。这不是推测，而是有大量线上案例佐证。

对于以PWA形式安装的网页，如果在iOS上卸载了这个PWA，部分版本会顺带连整个Origin下的IndexedDB一起清理干净。

另一个容易被忽视的场景：页面在后台挂起超过7天，期间没有任何点击、表单提交或其他显式交互。这种“零活跃”状态，会被WebKit内核直接标记为闲置垃圾，然后择机处理掉。

为什么不能依赖“数据库始终存在”这个假设

这不是Bug，这是设计。Safari不保证IndexedDB具有持久性。它只承诺“写入成功的那一刻是生效的”，但从不保证“下次打开网页时数据还在”。

一旦发生静默清理，页面加载时openRequest.onsuccess事件照样会触发，但objectStore.count()返回0。

更棘手的是，在onsuccess里你无法区分这是第一次初始化还是数据已被清除。这会导致一个非常隐蔽的问题：应用可能以为自己顺利打开了数据库，但实际上所有数据都丢了。

验证当前IndexedDB是否已被清空的最快方法

方法一：通过开发者工具查看。在Safari中打开目标网页，按Command+Option+I调出开发者工具。切换到Storage标签，展开IndexedDB，直接看有没有数据库名以及objectStore列表，一目了然。

方法二：使用控制台命令。如果想更快一点，直接在控制台执行indexedDB.open("your-db-name").onsuccess = e => console.log(e.target.result.objectStoreNames)。如果输出是空的DOMStringList，说明数据库要么不存在，要么已经被重置了。

每次页面加载必须执行的初始化动作

系统可能悄无声息地清空数据库。因此应对策略必须部署在每一次页面加载时。

封装一个openDB函数，在onupgradeneeded和onsuccess两个回调里都要检查关键objectStore是否存在且非空。

如果检测到objectStore缺失或count()为0，必须立即从localStorage缓存中恢复基础配置，或者从CDN拉取默认数据集。

必须严格执行：每次在IndexedDB写入成功后，同步更新localStorage快照，只存ID、时间戳和摘要就够了。一旦这个恢复链断了，数据就再也找不回来了。

《夸克》非常好用的免费AI浏览器

下载APP查看