前端本地存储指南：从 localStorage 到 IndexedDB，技术优缺点与示例代码

作为一名前端程序员，总会面临一个问题：“用户的数据该往哪里放？” 这就好比一个咖啡店老板，想着咖啡豆要放仓库、柜台还是直接丢客户兜里。今天我们就来聊聊前端常用的本地存储技术，各自的优缺点，以及到底该选哪一个！

1. `localStorage` — 傻白甜的代名词

localStorage 是前端开发者最早接触到的本地存储方案之一，API 简单，只有 setItem、getItem 和 removeItem 三板斧。可存储最大 5MB 的数据，以键值对形式保存。

优点：

使用简单，像日常逛菜市场买菜一样直接。
永久保存，用户不清除，你的数据就永远在。

缺点：

数据是明文存储，和裸奔差不多，根本不安全。
只能存储字符串，存对象的话还得自己手动 JSON.stringify 和 JSON.parse。
同步操作，可能会影响性能（特别是你在存一大坨东西的时候）。

示例代码：

// 存储数据
localStorage.setItem('name', '小明'); // 将字符串 "小明" 存入 localStorage

// 读取数据
const name = localStorage.getItem('name'); // 从 localStorage 中取出 "name" 对应的值
console.log(name); // 小明

// 删除数据
localStorage.removeItem('name'); // 删除 "name" 键对应的数据

适合场景：放点无关紧要的小数据，比如记录用户是否看过你的新手引导弹窗。

2. `sessionStorage` — 速食面，吃完就没了

如果你觉得 localStorage 的 “永久” 特性让你有点不安，那可以试试 sessionStorage。它的作用范围只限于当前的标签页，关了页面数据就没了。

优点：

跟 localStorage 一样简单易用。
数据生命周期短，自动帮你清理。

缺点：

依然是明文存储，不安全。
数据只能存活在当前标签页，无法跨页面共享。

示例代码：

// 存储数据
sessionStorage.setItem('temp', '12345'); // 存入临时数据 "12345"

// 读取数据
const temp = sessionStorage.getItem('temp'); // 获取 "temp" 键对应的值
console.log(temp); // 12345

// 清除所有数据
sessionStorage.clear(); // 清空当前标签页的所有 sessionStorage 数据

适合场景：存些临时数据，比如分页表格的滚动条位置。

3. `Cookies` — 从前端到后端的一座桥

Cookies 早已是老朋友了，虽然现在很多地方都用它来配合后端做鉴权，但它其实也是本地存储的一种方式。

优点：

可自动携带到服务端，适合存放需要传到后端的小数据。
数据生存周期可以配置，从几秒到几年随心所欲。

缺点：

大小限制（约 4KB），空间比 localStorage 还抠门。
容易造成网络请求臃肿，毕竟每次请求都会附带上去。
不适合存放敏感信息，依然容易被拦截。

示例代码：

// 设置一个 cookie，内容为 "user=小明"，过期时间为 2024 年 12 月 31 日
const expires = "Fri, 31 Dec 2024 23:59:59 GMT";
document.cookie = `user=小明; expires=${expires}`;

// 读取 cookie
console.log(document.cookie); // 输出所有 cookie，比如 "user=小明"

适合场景：放用户的 token 或 session ID。

4. `IndexedDB` — 前端的数据库老司机

如果你是一个对数据存储有更高要求的人（比如存储几百 MB 的图片或者复杂的 JSON 数据），那 IndexedDB 就是你的最佳拍档了。它是一个浏览器提供的 NoSQL 数据库，可以存储大量数据，支持事务操作，API 相对复杂，但功能非常强大。

优点：

数据量大到起飞，别说 5MB，几百 MB 都不在话下。
数据结构灵活，支持对象存储，天生适合复杂数据。
异步操作，不会阻塞主线程，性能高。
更加安全，存储在沙箱环境中。

缺点：

API 复杂，光 open 数据库就要写一堆回调。
浏览器兼容性虽然主流都支持，但坑还是不少。
学习曲线相对陡峭。

示例代码：

// 打开一个名为 "MyDatabase" 的数据库，版本号为 1
const request = indexedDB.open('MyDatabase', 1);

// 数据库打开成功
request.onsuccess = (event) => {
  const db = event.target.result; // 获取数据库实例
  console.log('数据库打开成功', db);

  // 插入数据
  const transaction = db.transaction('MyStore', 'readwrite'); // 创建事务
  const store = transaction.objectStore('MyStore'); // 获取对象存储
  store.add({ id: 1, name: '小明', age: 25 }); // 添加数据

  // 查询数据
  const getRequest = store.get(1); // 查询主键为 1 的数据
  getRequest.onsuccess = () => {
    console.log('查询成功', getRequest.result);
  };

  // 更新数据
  store.put({ id: 1, name: '小红', age: 26 }); // 更新主键为 1 的数据

  // 删除数据
  store.delete(1); // 删除主键为 1 的数据

  transaction.oncomplete = () => {
    console.log('所有操作完成');
  };
};

// 数据库打开失败
request.onerror = (event) => {
  console.error('数据库打开失败', event);
};

// 数据库首次创建或版本号更新时触发
request.onupgradeneeded = (event) => {
  const db = event.target.result; // 获取数据库实例
  console.log('正在初始化数据库...');

  // 如果不存在名为 "MyStore" 的对象存储仓库，则创建它
  if (!db.objectStoreNames.contains('MyStore')) {
    db.createObjectStore('MyStore', { keyPath: 'id' }); // 指定主键为 "id"
  }
};

适合场景：需要存储大量、复杂、频繁访问的数据，比如离线模式的电商购物车、待同步的用户草稿。

那到底该用谁？

选择存储技术之前，先问问自己三个问题：

数据需要多大？
- 如果小于 5MB，localStorage、sessionStorage 都可以考虑。
- 如果需要存大文件，直接上 IndexedDB。
数据生命周期有多长？
- 需要长期保存的，用 localStorage 或 IndexedDB。
- 临时用完就扔的，sessionStorage 更合适。
数据的安全性要求高吗？
- 不安全的就别用 localStorage 和 sessionStorage。
- 需要更高的安全性，就用 IndexedDB，或者干脆加密后再存。

结语

本地存储技术就像超市货架上的零食，每种都有自己的独特味道和最佳食用方法。下次你在项目中遇到存储问题时，想想这些特点，选一个最适合的工具，让你的用户体验更加丝滑顺畅！

最后，记住一点：不要在本地存储敏感数据，毕竟浏览器再牛也不是保险箱，真正安全的数据，还是交给后端去守护吧！

1. localStorage — 傻白甜的代名词

2. sessionStorage — 速食面，吃完就没了

3. Cookies — 从前端到后端的一座桥

4. IndexedDB — 前端的数据库老司机

那到底该用谁？

结语

猜你喜欢

目录

热门文章

1. `localStorage` — 傻白甜的代名词

2. `sessionStorage` — 速食面，吃完就没了

3. `Cookies` — 从前端到后端的一座桥

4. `IndexedDB` — 前端的数据库老司机