localStorage与IndexedDB使用教程

偷偷努力，悄无声息地变强，然后惊艳所有人！哈哈，小伙伴们又来学习啦~今天我将给大家介绍《JavaScript操作浏览器存储：localStorage与IndexedDB实战教程》，这篇文章主要会讲到等等知识点，不知道大家对其都有多少了解，下面我们就一起来看一吧！当然，非常希望大家能多多评论，给出合理的建议，我们一起学习，一起进步！

localStorage仅支持字符串值，存对象或数组须显式JSON序列化，否则取值时崩溃；IndexedDB才是真正的离线数据库，需通过onupgradeneeded建库建表，所有操作必须在transaction内执行。

localStorage 适合存小量结构简单、不常更新的键值对；IndexedDB 才是真正能支撑离线应用、批量读写、索引查询的浏览器本地数据库——别用 localStorage 存数组或对象后直接 JSON.stringify 就以为万事大吉，那只是把问题推迟到取值时崩溃。

localStorage 的正确写法与典型翻车点

它只接受字符串作为值，setItem 会静默调用 toString()，导致对象变成 [object Object]，数组变成逗号拼接字符串。存之前必须显式序列化，取之后必须显式反序列化。

常见错误现象：

• 存了 { user: { id: 1, name: "Alice" } }，取出来是 "[object Object]"
• 存了 [1, 2, 3]，取出来是 "1,2,3"，再 JSON.parse 报错
• 存了含 undefined 或函数的对象，JSON.stringify 直接丢掉字段，还原后数据不全

实操建议：

• 始终用 JSON.stringify 存，用 JSON.parse 取，且加 try/catch
• 避免存超大字符串（Chrome 限制约 5–10MB，但实际超过 2MB 就可能卡主线程）
• 不要依赖 localStorage 做状态同步——它不触发跨 tab 的 storage 事件（除非是其他 tab 修改）

const saveUser = (user) => {
  try {
    localStorage.setItem('user', JSON.stringify(user));
  } catch (e) {
    console.error('localStorage write failed:', e);
  }
};

const loadUser = () => {
  const raw = localStorage.getItem('user');
  if (!raw) return null;
  try {
    return JSON.parse(raw);
  } catch (e) {
    console.error('localStorage parse failed:', e);
    return null;
  }
};

IndexedDB 创建数据库与对象仓库的最小可行步骤

IndexedDB 不是“打开即用”，必须先发请求建库、等 onupgradeneeded，再在回调里定义 objectStore 和 index。跳过这步，后续所有 add/get 都会报 InvalidStateError。

关键点：

• indexedDB.open 第二个参数是版本号，**必须是整数**，升级时改它才会触发 onupgradeneeded
• 在 onupgradeneeded 中用 db.createObjectStore 创建仓库，不能在 onsuccess 里做
• 首次打开或版本升级时，onupgradeneeded 必定执行；已存在且版本未变，则跳过

const openDB = () => {
  return new Promise((resolve, reject) => {
    const req = indexedDB.open('myAppDB', 1);
    req.onerror = () => reject(req.error);
    req.onsuccess = () => resolve(req.result);

    req.onupgradeneeded = (event) => {
      const db = event.target.result;
      if (!db.objectStoreNames.contains('users')) {
        const store = db.createObjectStore('users', { keyPath: 'id' });
        store.createIndex('by_email', 'email', { unique: true });
      }
    };
  });
};

用 transaction 确保读写安全：为什么不能直接调 store.get

IndexedDB 所有操作都必须包裹在 transaction 内，哪怕只是读一个值。直接访问 objectStore 属性会报 InvalidStateError: Cannot access object store outside a transaction。

使用场景差异：

• readonly 事务支持并发读，适合列表页加载
• readwrite 事务自动排队，适合表单提交、状态更新
• 事务生命周期 = 回调函数执行完 + 所有请求完成，**不是**函数返回就结束

容易踩的坑：

• 在 transaction.oncomplete 外访问结果——此时数据可能还没写入磁盘
• 重复使用同一个事务对象跨异步操作（如 await 后再用），事务早已关闭
• 忘记指定 mode，默认是 readonly，写操作直接失败

const getUserById = async (db, id) => {
  return new Promise((resolve, reject) => {
    const tx = db.transaction('users', 'readonly');
    const store = tx.objectStore('users');
    const req = store.get(id);
    req.onsuccess = () => resolve(req.result);
    req.onerror = () => reject(req.error);
  });
};

localStorage 与 IndexedDB 混用时的数据一致性陷阱

有人用 localStorage 缓存 IndexedDB 查询结果来提速，结果改了 DB 却忘了清 localStorage，用户看到的是旧数据。这不是“缓存策略”，是 bug 温床。

实操建议：

• 避免双写——要么全走 IndexedDB，要么只用 localStorage 存 UI 状态（如折叠面板开关）这类与服务端无关的数据
• 如果非要缓存，把清理逻辑绑定到 IndexedDB transaction 的 oncomplete，而不是靠定时器或手动清除
• 注意 IndexedDB 是异步、localStorage 是同步——混用时别假设“刚存完 DB 就能从 localStorage 读到最新值”

最常被忽略的一点：IndexedDB 的 keyPath 和 index 一旦设错，升级时删库重建是唯一干净解法；而 localStorage 没有 schema，坏数据只会让 JSON.parse 在某次启动时突然失败——前者问题暴露早，后者问题藏得深。

以上就是《localStorage与IndexedDB使用教程》的详细内容，更多关于的资料请关注golang学习网公众号！