IndexedDB本身不拖慢离线存储，但事务滥用、未分块写入、大对象同步序列化、串行回调、未设readwriteflush模式等错误用法会导致卡顿；其优势在于异步、索引与事务支持，适合复杂离线场景。
IndexedDB 本身不会拖慢离线存储——它就是为离线存储而生的，但用错方式、忽略事务边界或滥用同步操作，确实会让页面卡顿、数据写入变慢，甚至触发浏览器降级策略。
IndexedDB 写入慢的常见原因和对应解法
不是 API 慢，是调用姿势不对。最常踩的坑集中在事务生命周期和数据序列化上：
-
put()或add()在长事务中批量写入时没分块，导致事务锁住整个 objectStore 数秒以上 - 直接把未压缩的
Blob或大 JSON 对象塞进put()，触发主线程阻塞式序列化（尤其在 Safari 和旧版 Chrome） - 在
onsuccess回调里立刻发起下一个写请求，形成串行阻塞链，而非用 Promise 链或async/await控制并发 - 没设
transaction.mode = 'readwriteflush'（Chrome 120+ 支持），默认readwrite不保证立即落盘，可能堆积在内存缓冲区，影响后续读取一致性
对比 localStorage：为什么 IndexedDB 更适合离线但更“重”
localStorage 是同步、键值对、无索引、5MB 封顶；IndexedDB 是异步、对象存储、支持索引与事务、容量达 GB 级——二者根本不在一个设计维度上。
如果你只是存个用户偏好设置，用 localStorage.setItem('theme', 'dark') 更轻量；但一旦要存几十条带时间戳的离线表单、附件 Blob、或需要按状态 + 创建时间范围查询的数据，localStorage 就会暴露三方面短板：
DeepBI DHTML 页面生成器
下载
生成可在 deepbi 沙箱 iframe 内运行或作为独立文件运行的交互式 HTML 页面，使用 `window.deepbi` JS SDK 实现数据查询、空间管理、文件浏览及用户操作。当用户提出以下需求时启用该能力： - 创建 KPI 仪表盘、数据表格、文件浏览器、成员列表、管理页面； - 明确要求“转成 dhtml”、“转译成 HTML”、“把 XX 页面转成……”、“控制台页面”、“管理后台”、“DeepBI 页面迁移”； - 提及位于 `apps/console/src/featur
- 每次
getItem()都得全量反序列化字符串，查一条要 parse 整个数组 - 没法按字段建索引，filter() 查数据是 O(n) 扫描，1000 条起步就明显卡顿
- 超过 5MB 直接报
QuotaExceededError，且无法预判剩余空间（navigator.storage.estimate()对 localStorage 不生效）
IndexedDB 查询快的关键：索引不是可选项，是必选项
没建索引的 cursor 遍历等同于全表扫描，10 万条记录可能耗时 800ms+（实测 Chrome 123）。加索引不是“以后再优化”，而是建库时就要定好。
立即学习“前端免费学习笔记（深入）”；
- 高频查询字段必须建单字段索引，例如
status、created_at - 复合查询如
where status = 'pending' and created_at > 1712131200000，需建复合索引，且顺序必须是status在前（高选择性字段优先） - 索引字段类型要和查询值一致：用
IDBKeyRange.lowerBound(new Date().getTime())查数字时间戳，别用字符串格式的'2026-04-03' - 删数据别只靠
clear()，它不释放索引空间；应走delete()+keyRange精准清理，再手动objectStore.deleteIndex('xxx')重建索引（仅当结构变更时）
离线场景下 IndexedDB 的真实瓶颈往往不在数据库本身
真正拖慢离线体验的，通常是开发者没处理好的边界逻辑：
- 离线时仍尝试发网络请求再 fallback 到
IndexedDB，而不是优先读库、异步补同步——这会让用户多等 1~3 秒才看到数据 - 没监听
upgradeneeded，版本升级失败后静默降级到旧 schema，导致后续get()返回undefined却不报错 - 在 Service Worker 中打开
IndexedDB时没用self.indexedDB.open()而是复用页面上下文，导致 SW 启动阶段 DB 打开失败（SW 没 window） - 没做写入失败重试兜底：网络恢复后，应从
pending_sync表捞出未提交记录，而不是指望用户手动点“同步”按钮
IndexedDB 的复杂度藏在事务控制、索引设计和错误恢复路径里，不是 API 调用难，而是每个 open()、transaction()、put() 都带着隐含约束。跳过这些细节，它就会从“离线利器”变成“卡顿元凶”。 
