IndexedDB实战指南：前端数据存储的高效方案与踩坑经验
シ慧芳优化前：卡得不行
上周上线一个离线数据缓存功能，用的是 IndexedDB。结果用户一多、数据量一大，页面直接卡成幻灯片——打开一个列表页要等 5 秒以上，滚动还掉帧。我本地测试时没感觉，因为只有几十条数据；但线上用户同步了几千条记录后，问题就炸了。
最离谱的是，每次切换标签页或者重新进入页面，都要重新从数据库读一遍，连个缓存都没有。我盯着 DevTools 的 Performance 面板看了半天，发现主线程被大量 IDBObjectStore.get 和 cursor 操作占满，CPU 直接飙到 90%+。这哪是优化，简直是自残。
找到瓶颈了！
先用 Chrome DevTools 的 Application 面板看了一下 IndexedDB 的结构，确认 schema 没写错。然后打开 Performance 录制，果然看到一堆长任务（Long Tasks），每个都超过 100ms，全是数据库操作。再切到 Memory 面板，发现频繁的 getAll 调用导致内存波动剧烈，GC 压力山大。
关键问题出在两个地方：
- 一次性读取全部数据（几千条）到内存，再做前端过滤和分页
- 没有用索引，全表扫描
说白了，就是把 IndexedDB 当成 localStorage 用了——一股脑塞进去，一股脑掏出来，完全没发挥它的查询能力。
核心优化方案：别一次读完，用游标 + 索引分页
折腾了半天，最后决定放弃“全量加载 + 前端过滤”的懒人做法，改成分页按需加载。同时，给常用查询字段建索引，避免全表扫描。
先看优化前的代码（反面教材）：
// 优化前：灾难现场
async function loadAllData() {
const db = await openDB();
const tx = db.transaction('items', 'readonly');
const store = tx.objectStore('items');
const all = await store.getAll(); // 一次性读几千条
return all.filter(item => item.status === 'active'); // 前端过滤
}这种写法在数据量小的时候没问题，但一旦上千条，getAll() 就会阻塞主线程，而且 filter 还得再遍历一遍，双重打击。
优化后，我做了两件事：
- 给
status字段加索引 - 用游标（cursor）配合
advance()实现分页，每次只取 20 条
建索引很简单，在 onupgradeneeded 里加一行：
// 在 onupgradeneeded 回调中
const store = db.createObjectStore('items', { keyPath: 'id' });
store.createIndex('by_status', 'status', { unique: false }); // 关键！然后重写查询逻辑，用索引 + 游标分页：
async function loadPageByStatus(status, page = 0, limit = 20) {
const db = await openDB();
const tx = db.transaction('items', 'readonly');
const store = tx.objectStore('items');
const index = store.index('by_status');
return new Promise((resolve) => {
const results = [];
let count = 0;
const skip = page * limit;
const request = index.openCursor(IDBKeyRange.only(status));
request.onsuccess = (event) => {
const cursor = event.target.result;
if (cursor) {
if (count >= skip && results.length < limit) {
results.push(cursor.value);
}
count++;
cursor.continue();
} else {
resolve(results);
}
};
});
}这里注意我踩过好几次坑：openCursor 默认是升序，如果数据量极大，skip 太多也会慢。所以后来我干脆改用 IDBKeyRange.bound 配合上一页的最后一条记录的 key，实现“基于游标的分页”，但考虑到项目时间紧，先用 skip 顶一下，实测 2000 条以内影响不大。
批量写入也得优化：别一条一条 put
除了读，写入也是个坑。之前同步数据时，是这样写的：
// 优化前：逐条写入，慢得要死
async function syncItems(items) {
const db = await openDB();
for (const item of items) {
const tx = db.transaction('items', 'readwrite');
const store = tx.objectStore('items');
await store.put(item); // 每次都开新事务！
}
}每条数据都开一个事务，IndexedDB 内部要反复加锁、提交，性能极差。正确做法是：**一个事务搞定所有写入**。
// 优化后：单事务批量写入
async function syncItems(items) {
const db = await openDB();
const tx = db.transaction('items', 'readwrite');
const store = tx.objectStore('items');
for (const item of items) {
store.put(item); // 不要 await！
}
await tx.done; // 等整个事务完成
}这里的关键是：不要在循环里 await 每个 put，而是让所有操作排队，最后等 tx.done。亲测 1000 条数据写入从 8 秒降到 300ms 以内。
性能数据对比
在模拟 2000 条数据的环境下，做了前后对比：
- 列表首次加载时间：从 5.2s 降到 780ms
- 滚动流畅度：FPS 从 15 提升到 58+
- 内存占用：峰值从 120MB 降到 45MB
- 批量写入 1000 条：从 8.1s 降到 280ms
最关键的是，主线程不再被数据库操作长时间阻塞，用户交互响应快了很多。虽然首次加载还是比纯内存慢，但体验已经从“不可用”变成“可接受”了。
还有几个小技巧
顺便提几个次要但实用的点：
- 不要频繁打开/关闭数据库连接：IndexedDB 的
open是异步且有开销的，建议全局缓存db实例（注意处理版本升级） - 读写分离：读操作用
readonly事务，写用readwrite，避免不必要的锁竞争 - 大对象慎存：像 base64 图片这种，尽量存 URL，或者用单独的 store，避免拖慢主数据查询
另外，IndexedDB 本身是异步的，但如果你在 onsuccess 回调里做 heavy compute，还是会卡主线程。所以复杂逻辑可以丢给 Web Worker，不过这次项目没到那一步，暂时没动。
结尾：不完美但够用
改完之后，虽然还有个别边缘情况（比如极端大数据量下分页跳转还是有点慢），但整体体验提升巨大。毕竟不是所有场景都需要百万级数据支持，2000 条内流畅就行。
以上是我对 IndexedDB 性能优化的实战总结，核心就两点：**用索引避免全表扫描，用分页减少单次数据量**。批量写入也别忘了合并事务。
这个方案不是理论最优，但简单、有效、改动小。有更优的实现方式欢迎评论区交流，比如基于游标的无 skip 分页，或者结合 Service Worker 做预加载，我都想看看！
