浏览器按空间压力分层清理缓存：先内存缓存、再过期磁盘缓存、然后冷localStorage、最后非活跃IndexedDB；关键数据需通过定期访问、热度标记、专属缓存及校验机制主动保活。
浏览器不会“随机”删你的关键缓存，但它的淘汰机制确实有明确优先级和触发条件。想保住重要数据，得先看清它在什么情况下动你的 localStorage、IndexedDB 或 Service Worker 缓存，再针对性加固。
浏览器按空间压力分层清理，不是统一扫描
当磁盘或内存快满时，浏览器不会遍历所有网站数据平均删，而是按预设顺序逐层释放：
- 最先清掉临时内存缓存（memory cache），比如刚加载的图片、脚本片段，不持久、无风险；
- 接着清理过期的磁盘缓存（disk cache），依据 HTTP 响应头中的 Cache-Control 或 Expires 判断是否过期；
- 然后才轮到 localStorage ——但只清“最近最少使用”的条目，且仅在极端空间不足时触发；
- 最后才可能清理非活跃标签页的 IndexedDB 数据，前提是该数据库长时间没被当前页面访问过。
关键缓存被误删，往往因为“冷”而非“坏”
localStorage 和 IndexedDB 本身没有显式过期时间，但浏览器会根据使用频率打“热度标记”。如果你的页面长期不打开、或只读不写，它就会被系统判定为“冷数据”，优先淘汰。这不是 bug，是设计行为。
- 避免长期闲置：哪怕每月用一次，也建议在页面加载时执行一次
localStorage.setItem('last_used', Date.now())； - IndexedDB 可定期 ping：在后台定时任务（如 Service Worker 的
periodic sync）中打开数据库并读一个简单索引，维持活跃状态； - 不要把关键配置全压在 localStorage：对不可丢失的数据（如用户偏好、加密密钥），可配合 Cache API + Cache-Control: immutable 存静态资源，或用 IndexedDB 加上版本号校验。
主动控制权比被动等待更可靠
浏览器的自动淘汰逻辑你无法关闭，但可以大幅降低触发概率：
- 在 manifest.json 或网页 meta 中声明
对敏感页禁用磁盘缓存，避免被当成普通资源清理； - Service Worker 注册后，用
caches.open('essential-v1')创建专属缓存区，并在 install 事件中cache.addAll()预存核心 JS/CSS，这类缓存受 Cache API 生命周期管理，不参与浏览器常规淘汰流程； - 对必须保留的 localStorage 数据，加一层轻量校验：存入时附带时间戳和简单哈希，在页面启动时检查是否存在、是否超 90 天未更新，若异常则从备份源（如 IndexedDB 或远程兜底接口）恢复。
真正影响关键缓存存留的，从来不是“清不清”，而是“用不用”和“标不标”。系统只认热度和空间，不认重要性。把使用痕迹做实，把存储意图写明，比反复手动清理更有效。
