sessionStorage、localStorage、cookie与indexDB应用

最新推荐文章于 2024-07-25 09:24:40 发布

飞飞飞鱼

最新推荐文章于 2024-07-25 09:24:40 发布

阅读量925

点赞数 2

文章标签：前端 javascript 面试

本文链接：https://blog.csdn.net/qq_38217940/article/details/125360427

版权

sessionStorage、localStorage、cookie与indexDB应用

sessionStorage与localStorage
cookie
indexDB
总结

sessionStorage与localStorage

基础信息

sessionStorage 用于临时保存同一窗口(或标签页)的数据，在关闭窗口或标签页之后将会删除这些数据。
localStorage 用于永久保存的数据，同源（协议、域名、端口相同）的页面在不同的标签页都能访问到。
存储空间：sessionStorage、localStorage的存储空间都是5M，存储内容只能是字符串
作用域：sessionStorage的作用域是同源的页面在相同的标签页上都能访问到，localStorage是不同的标签页也可以访问到

使用方式

应该大家都指的，直接上代码

let key = 'mykey';
// 只能存字符串
sessionStorage.setItem(key, JSON.stringify({a:1}));
let value = sessionStorage.getItem(key);
// 取出来的别忘了转换格式
value = JSON.parse(value);
// 反复存储
sessionStorage.setItem(key, 1);
value = sessionStorage.getItem(key);
// 就算是存数字也是会被存成字符串
value = Number(value);
// localStorage使用方式跟sessionStorage相同
localStorage.setItem(key, 1);
value = localStorage.setItem(key);

// 删除所有保存的数据
sessionStorage.clear();
localStorage.clear();

使用场景

因为sessionStorage、localStorage都可以在跳转页面或者刷新页面时保持数据不被清除，所以可以在以下场景使用

用来做页面间的数据传递，比如多页面的时候从A页面跳转到B页面
加快页面渲染速度，数据存在storage中，刷新页面的时候不调接口直接从storage中取数据
localSotrage可以保存第一次进入页面的状态，比如一些基础信息，下次进入页面的时候先展示本地存储的信息，再调用接口刷新页面，可以减少用户的等待时间
因为sessionStorage关闭页面就清除数据，所以可以用于保存一些敏感数据（如账号信息），localStorage是永久保存，所以不能保存敏感信息
一些骚操作，如base64的图片也是可以保存的，但是容易把内存撑爆，所以内存过大的内容不要保存在storage里面

cookie

基本信息

cookie也是用户缓存，他主要用于存储一些重要的信息
cookie的大小是4kb
cookie会在每次请求的时候都发送给服务器，所以会影响请求速度
cookie的存在时间是可以设置的，不需要长时间保存的一定要及时删掉
cookie在服务器端也能设置，主要是以前用来传一些固定参数及token的（token的作用当前页面会话身份验证）
cookie不安全说的是用来保存token的时候，这里只讨论cookie的存储功能

使用方式

// 直接拿到字符串
let cookie = document.cookie;
// cookie的内容是这样的 "a=1;b=2;c=3"
// 简单的示例获取a
let a = cookie.split(';')[0].spilt('=')[1];
// 赋值
document.cookie = "d=4";
// 执行后cookie="d=4;a=1;b=2;c=3"
// 下面的写法打乱了队形，不要那么写
document.cookie = "4";
// 执行后cookie="4;d=4;a=1;b=2;c=3"
// 删除cookie
document.cookie = "d=''";

使用场景

不是场景非常特殊（比如很老的项目，已经用了）别用它，影响性能，存储空间小

indexDB

基本信息

IndexedDB 是一种底层 API，用于在客户端存储大量的结构化数据（也包括文件/二进制大型对象（blobs））
IndexedDB的主要特点是存储空间大，解决localStorage空间不够的问题，理论上是浏览器能存多少，它大概就能存多少，几G都是小的
indexDB查询是异步的，也就是在大数据查询的时候，异步不会阻塞js的事件循环

使用方式

indexDB的使用方式是相当复杂的，不是一篇博客能讲清楚的，如果要做的好，需要系统的学习结合实际应用的场景自己封装插件，这里只介绍一下使用的思路

封装基础的增删改查方法，简单点的可以使用第三方插件（下方有贴图）
indexDB需要专门一个表来储存版本信息、用户信息，同时在服务器也要有专门的表（一份json文件也可以）来存这些信息，每次使用indexDB前都要先调一个极快的接口来确认当前的数据是要用服务器的还是本地的
需要处理好异步操作的逻辑，因为indexDB是异步的，需要确保indexDB的查询跟服务器查询的时序，比如你想先用indexDB的数据快速展示，然后再调用远程的数据刷新本地数据，假如接口足够快，可能会比indexDB还要早请求到数据，那么时序就出问题了
需要考虑客户清缓存以及第一次进入页面的情况
要注意哪些数据是要离开界面时要删掉的（sessionStorage空间不够时），及时清除
基本使用方式这里贴一下MDN的示例，

// 我们的客户数据看起来像这样。
const customerData = [
  { ssn: "444-44-4444", name: "Bill", age: 35, email: "bill@company.com" },
  { ssn: "555-55-5555", name: "Donna", age: 32, email: "donna@home.org" }
];
const dbName = "the_name";

var request = indexedDB.open(dbName, 2);

request.onerror = function(event) {
  // 错误处理
};
request.onupgradeneeded = function(event) {
  var db = event.target.result;

  // 建立一个对象仓库来存储我们客户的相关信息，我们选择 ssn 作为键路径（key path）
  // 因为 ssn 可以保证是不重复的
  var objectStore = db.createObjectStore("customers", { keyPath: "ssn" });

  // 建立一个索引来通过姓名来搜索客户。名字可能会重复，所以我们不能使用 unique 索引
  objectStore.createIndex("name", "name", { unique: false });

  // 使用邮箱建立索引，我们向确保客户的邮箱不会重复，所以我们使用 unique 索引
  objectStore.createIndex("email", "email", { unique: true });

  // 使用事务的 oncomplete 事件确保在插入数据前对象仓库已经创建完毕
  objectStore.transaction.oncomplete = function(event) {
    // 将数据保存到新创建的对象仓库
    var customerObjectStore = db.transaction("customers", "readwrite").objectStore("customers");
    customerData.forEach(function(customer) {
      customerObjectStore.add(customer);
    });
  };
};

想要深入研究的推荐直接看MDN地址，而且它上面还推荐了一些实用的插件。或者是专门找一些书籍来看（作者也没看过啥书，没得推荐），博客作者看过不少，质量都不是很行，所以作者也觉得自己写不出啥高深的内容，只能简单介绍下
在这里插入图片描述

使用场景

大前提，不能有泄露客户隐私的敏感数据，数据量够大，localStorage不够用，没有必要的话，不要杀鸡用牛刀
gis项目，有很多的地理信息数据要存，比如一份静态的geojson可能就10几兆，几千几万条数据，可以存在indexDB按需使用，因为十几兆的数据存在js里面反复使用，经常会使页面崩溃
可视化大屏项目，很多公司做大数据可视化，经常是内部使用的，给的服务器性能又差，接口经常都是很慢的，可以存大量的数据在本地，加快第二次打开的速度，对比localStorage的优势当然是存得多，而且因为是公司内部使用的，基本上所有信息都能往里面存
自家的app里面的h5页面，因为app是自家公司的，本地数据安全方面做好了，可以放心大胆的多存一些数据在本地，可以优化h5页面的性能
大型平台，有很多共享数据要传递，因为storage都是同域名公用的，大家都往里面存东西，有时候会把存储空间撑爆了，作者就遇到过猪队友往localStorage里面存了base64，导致作者找不到自己存的数据。因为indexDB的空间够大，别说base64，二进制都能存，盘它就对了
因为它是异步的，大数据量的查询时使用它避免阻塞。比如十万条数据拿到手（已经有地方用上了），这时候需要取特定的某一条，你用js同步过滤，计算肯定会阻塞主事件循环，也可以调后端接口，但是Web Worker 、indexDB也可以作为解决方案，当你没有更好的方案时，使用它也是不错的选择

关于indexDB，好多东西作者也在发掘，就写这么多，想到了再补充。

总结

sessionStorage、localStorage、indexDB都是用户缓存，同源页面共享，主要用途都是提升性能、传递参数，差别就在于数据量、作用域、生命周期。
个人的小建议，如果服务器性能极佳，尽量不要在客户端存太多数据，你不能保证你存的数据一定是不敏感的，存得越多，风险越大。优先使用sessionStorage，其次localStorage，最后indexDB。cookie能不用就不用。