indexeddb 存储的二进制资源生命周期与数据库一致，永久存在直至手动清除或显式删除；其直接序列化存储，不依赖页面会话，可通过 count()、get()、事件监听及哈希校验等方式轻量监控存续状态。
IndexedDB 存储二进制资源（如 Blob、ArrayBuffer）时，其生命周期完全由数据库本身管理，不依赖页面会话或标签页状态——只要数据库未被用户手动清除或脚本显式删除，这些二进制数据就持续存在。
二进制数据的存储与生命周期绑定数据库
IndexedDB 中的 Blob 和 ArrayBuffer 是直接序列化写入对象存储（Object Store）的，不是引用外部文件或内存地址。这意味着：
- 数据持久化级别与整个 IndexedDB 数据库一致：永久存储，除非用户在浏览器设置中清除网站数据，或代码调用
indexedDB.deleteDatabase() - 不随页面刷新、标签页关闭、甚至浏览器重启而丢失
- 不受 sessionStorage 或 localStorage 的会话限制影响
如何监控二进制资源的存续状态
没有内置的“过期时间”或自动清理机制，所以监控重点在于验证数据是否仍可读取、数据库是否可用：
- 定期执行轻量级探测：用
transaction.objectStore(name).count()或get()检查关键记录是否存在，避免全量遍历 - 监听
upgradeneeded和blocked事件，判断数据库是否因版本冲突或被其他实例阻塞而无法访问 - 捕获
versionchange事件（在其他标签页调用deleteDatabase或升级时触发），及时提示用户或触发本地缓存重建
实际开发中的生命周期风险点
看似“永久”，但以下情况会导致二进制资源意外丢失：
- 用户主动清除浏览器缓存+网站数据（Chrome/Firefox 默认勾选 IndexedDB）
- 代码中误删 Object Store 或整个数据库（例如迁移逻辑错误导致
db.createObjectStore覆盖前未备份） - PWA 场景下，Service Worker 触发的 Cache API 清理不会影响 IndexedDB，但开发者若混用并统一清理策略，可能连带误删
- 移动端 Safari 对 IndexedDB 容量更敏感，在存储接近上限时可能静默裁剪旧数据（无标准规范，属实现差异）
推荐的轻量监控实践
无需复杂轮询，可在关键路径加入一次校验：
- 应用启动时，尝试打开数据库并读取一个已知 Blob 记录的 size 属性（
request.result.size），确认可访问且非 0 - 对大文件做哈希摘要（如 SHA-256）并单独存为元数据字段，后续可通过比对摘要验证完整性
- 结合 StorageManager API（如
navigator.storage.estimate()）预估剩余空间，提前预警容量风险
