indexeddb是浏览器端支持事务、索引和gb级存储的高性能本地nosql数据库，需通过合理建模、精准索引、分批写入与主动清理实现高效应用。

IndexedDB 是浏览器端最强大的本地数据库，适合存储结构化数据、支持事务、索引和大量数据（GB 级别在现代浏览器中已可行）。它不是简单“缓存”，而是可持久、可查询、可增删改查的客户端数据库。要真正用好它做高性能本地缓存，关键不在“存”，而在“怎么建模、怎么索引、怎么分片、怎么清理”。

合理设计 Object Store 与主键策略

每个数据库由多个 object store（类似表）组成。设计时避免“一个 store 存所有数据”的反模式：

• 按业务域拆分 store：例如 articles、user_profiles、offline_queues，便于权限控制和批量清理
• 主键（keyPath）优先选业务唯一字段（如 id），避免用自增数字——后者在多端同步或离线写入时易冲突
• 若需复合查询（如按 category + timestamp 范围查），不依赖主键，而用 multiEntry 索引 + keyRange

索引不是越多越好，但关键查询必须有对应索引

IndexedDB 查询性能极度依赖索引。没有索引的 get/all 查询只能全表扫描，海量数据下会卡死 UI 线程：

• 对高频过滤字段（如 status、updated_at、tenant_id）显式创建索引，设置 unique: false 和 multiEntry: false 即可
• 对时间范围查询（如“最近7天消息”），建立 updated_at 索引后，用 IDBKeyRange.bound(start, end) 高效定位
• 避免在长文本字段（如 content）上建索引；全文搜索应交由 FlexSearch 或 tantivy-wasm 等专用库处理

分块写入 + 批量事务，防止阻塞主线程

一次性 put 10 万条记录会触发长时间事务，导致页面冻结甚至被浏览器终止：

• 将大数据集切分为每批 500–2000 条，用 transaction.objectStore().add() 批量写入
• 每次写入后 await 下一个 transaction，利用微任务间隙让出主线程（可用 queueMicrotask 或 setTimeout(..., 0) 控制节奏）
• 开启事务时明确指定 scope：db.transaction(['logs'], 'readwrite')，避免意外锁住无关 store

主动管理容量与生命周期，避免无限膨胀

IndexedDB 不会自动清理，长期运行的应用可能占满配额（通常为磁盘空间的 ~50%，但各浏览器差异大）：

• 为每类数据设定 TTL（如缓存文章保留 30 天），插入时存 expiresAt 字段，定期用游标遍历过期项并 delete
• 监听 storage 事件或使用 navigator.storage.estimate() 主动监控用量，接近限额（如 >80%）时触发分级清理（先删临时队列，再删旧日志）
• 敏感数据（如 token、PII）绝不存 IndexedDB；必须存时，配合 Web Crypto API 加密后再写入

不复杂但容易忽略：IndexedDB 的错误不可忽视。所有 open、transaction、request 都要监听 onerror 和 onsuccess，失败时降级到内存 Map 缓存或报错提示，而不是静默失败。