核心是分块写入+合理建模+复合索引设计：按500–1000条分批提交事务，主键用业务ID并扁平化字段，用['dept','status']等数组创建复合索引支持多维查询，写入前校验ID去重。
用 IndexedDB 存储超大列表并支持二级索引，核心是分块写入 + 合理建模 + 复合索引设计。不一次性塞入全部数据，也不依赖单字段索引查多维条件。
分批写入避免阻塞和内存溢出
从 API 拉取的列表动辄上万条，直接 bulkAdd 会卡死页面或触发事务超时。应按每 500–1000 条为一批，用 transaction 分批次提交：
- 每次 fetch 后切片（如
data.slice(i, i + 800)），逐批调用objectStore.add()或put() - 每批写完监听
transaction.oncomplete再处理下一批，确保事务串行、不冲突 - 加 loading 状态与进度提示（如“已存 2400/12500”），避免用户误操作
按查询场景设计对象结构和主键
别直接存原始 API 返回对象。先归一化字段，明确主键与常用查询维度：
- 主键建议用业务唯一 ID（如
id），而非自增数字，方便后续更新和关联 - 把高频筛选字段提前“扁平化”，例如原始数据含
{user: {name: 'A', dept: 'RD'}, status: 'active'}，存为{id: 'u1001', userName: 'A', dept: 'RD', status: 'active', …} - 避免深层嵌套——IndexedDB 不支持对
user.name这类路径建索引
用 compound index（复合索引）实现二级索引
所谓“二级索引”，本质是基于多个字段联合查询。IndexedDB 通过 createIndex(name, keyPath, options) 支持数组形式的 keyPath：
- 例如按部门 + 状态查：创建索引
store.createIndex('byDeptAndStatus', ['dept', 'status']) - 查询时用
index.getAll(IDBKeyRange.bound(['RD', 'active'], ['RD', 'pending']))，注意边界值顺序必须匹配索引字段顺序 - 若还需按时间倒序，可加第三字段：
['dept', 'status', 'updatedAt']，再配合openCursor(null, 'prev')实现倒序遍历
增量更新与去重写入
API 可能分页拉取或定时刷新，需避免重复插入相同记录：
- 写入前用
objectStore.get(id)判断是否存在；存在则用put()覆盖，不存在再add() - 或统一用
put()（它自动替换），前提是主键可靠且服务端保证 ID 全局唯一 - 批量更新时，可先用
getAllKeys()获取本地已有 ID 集合，再比对后只写入差异项（适合离线优先场景）
不需要额外库，原生 IndexedDB 就能胜任。关键是建模想清楚、写入控节奏、索引对准真实查询逻辑。
