IndexedDB 实战：为离线待办应用打造可靠的本地数据层

做离线应用时，很多人的第一反应是 localStorage：简单、同步、随取随用。但它有两个硬伤：容量只有约 5MB，存取还都是字符串，复杂结构要反复序列化；更关键的是读写会阻塞主线程，数据量一大页面就卡顿。IndexedDB 才是浏览器里真正的本地数据库：异步操作、支持索引、容量可达磁盘的很大一部分，适合做待办清单、离线笔记这类需要结构化存储的场景。

一、先设计库结构，再写代码

IndexedDB 的核心概念只有三个：数据库、对象仓库（类似表）、事务。给待办应用建库时，建议一个库只放一类业务数据，仓库按主键自增，常用的查询字段单独建索引。例如 todos 仓库以 id 为主键自增，再给 status 和 createdAt 建索引，分别支撑“按状态筛选”和“按时间排序”两种查询，避免全表扫描。

二、用 Promise 封装，别直接写回调

原生 API 是事件回调风格，层层嵌套很难维护。实际项目里可以先写一个 openDB 的 Promise 封装：打开数据库时指定版本号，在 onupgradeneeded 里创建仓库和索引；读写操作统一包成返回 Promise 的小函数，调用方直接用 async/await。这样业务代码读起来就是顺序的增删改查，出错时也能用 try/catch 统一处理。

三、事务是有生命周期的

新手最容易踩的坑是事务自动提交：一个事务一旦脱离当前事件循环、没有新的请求挂上去，就会自动提交，之后再操作会抛错。所以正确姿势是打开事务后立即把所有请求都发起，不要在事务中间插入 await 去请求网络或等用户输入；先把数据准备好，再一次性发起读写请求。需要多仓库联动时，用同一个事务跨仓库操作，任何一步失败整体回滚。

四、别忘了配额与降级

浏览器给每个源分配的空间不是无限的，超出配额会触发 QuotaExceededError。写入前可以先用 navigator.storage.estimate() 查看剩余空间，重要数据写失败时给用户明确提示，而不是悄悄丢弃。另外要留降级路径：隐私模式或老旧浏览器不支持 IndexedDB 时，退回 localStorage 做最小可用存储，保证核心流程不断。

五、一个可直接用的最小封装

const dbPromise = openDB('todo-app', 1, (db) => {
  const store = db.createObjectStore('todos', { keyPath: 'id', autoIncrement: true });
  store.createIndex('by-status', 'status');
  store.createIndex('by-created', 'createdAt');
});

async function addTodo(title) {
  const db = await dbPromise;
  return db.add('todos', { title, status: 'active', createdAt: Date.now() });
}

async function listActiveTodos() {
  const db = await dbPromise;
  return db.getAllFromIndex('todos', 'by-status', 'active');
}

结语

IndexedDB 的 API 看起来啰嗦，但它解决的是 localStorage 解决不了的问题：大数据量、结构化查询、异步不阻塞。掌握“设计索引、封装 Promise、尊重事务生命周期”这三点，就能给离线应用搭一个可靠的本地数据层；再配上定期的云端同步，一个真正可用的离线优先应用就成型了。