indexeddb 数据持久化可靠性高但非绝对不丢，依赖正确使用事务、错误处理及环境适配；成功提交事务后数据落盘，支持跨会话读取，但受浏览器配额、隐私模式和移动端策略影响。
IndexedDB 的数据持久化可靠性整体较高，但不是“绝对不丢”，其实际表现取决于使用方式、环境条件和错误处理是否到位。
持久性机制真实有效
IndexedDB 是浏览器原生支持的永久性存储方案，数据写入成功后会落盘保存，不受页面刷新、标签关闭甚至浏览器意外崩溃影响。它不像 localStorage 那样依赖内存缓存或会话状态，也不像 sessionStorage 那样随标签销毁而清空。在 Chrome、Firefox、Edge 等主流浏览器中，只要事务成功提交（oncomplete 触发），数据就已写入磁盘，重启后仍可读取。
事务保障是可靠性的核心前提
所有写操作必须包裹在 readwrite 事务中，这是保证原子性和一致性的关键：
- 任一请求失败（如主键冲突、存储空间不足、类型不匹配）将导致整个事务自动中止并回滚，避免部分写入造成数据错乱
- 需监听 transaction.onerror 和 transaction.onabort，及时捕获 ConstraintError、QuotaExceededError 等典型异常
- 不能在 setTimeout 或事件循环外异步调用 store 方法，否则事务可能已结束，引发 InvalidStateError
容量与生命周期受浏览器策略约束
虽然 IndexedDB 没有硬性上限，但实际可用空间由浏览器动态配额决定：
- Chrome 允许最多占用用户空闲磁盘空间的 80%，但首次使用时可能只分配几十 MB，后续按需增长
- 当系统磁盘紧张或用户手动清除网站数据时，IndexedDB 数据会被一并删除
- 在隐私模式（无痕窗口）下，数据仅保留至会话结束，关闭窗口即清空
跨场景稳定性差异明显
不同运行环境对持久化效果有直接影响：
- Electron 应用：基于 Chromium 内核，IndexedDB 表现稳定，且不受同源策略限制，适合长期本地缓存
- 浏览器扩展（如 Plasmo）：需配合后台服务保活，防止扩展休眠导致连接中断；建议用 BroadcastChannel 同步多窗口状态
- 移动端 Safari：存在更严格的清理策略，长时间未访问的 IndexedDB 可能被静默回收，需定期 touch 或设计降级 fallback
工程实践中提升可靠性的关键动作
仅靠 API 默认行为不足以应对真实业务压力，需主动加固：
- 写入后不依赖“无报错”就认为成功，应等待 transaction.oncomplete 再更新 UI 或触发后续逻辑
- 对关键操作（如电子病历保存、财务记录）增加轻量校验：写入后立即 get 回读比对
- 避免单一大事务写入海量数据，改用分批 + 递归提交，降低失败概率和重试成本
- 结合 KV.js、Dexie.js 等封装库，利用其内置的错误重试、过期清理、初始化兜底等能力
