深入浅出前端本地储存

• 举个例子，在一些使用 Cookie 保持登录态的网站上，如果 Cookie 被窃取，他人很容易利用你的 Cookie 来假扮成你登录网站

• 当然可以用 Session 配合 Cookie 来缓解这个问题，但是 Session 会占用额外的服务器资源

• Cookie 每次请求自动发送的特性还会导致 CSRF 攻击的安全风险

• Cookie 只允许储存 4kb 的数据

• Cookie 的操作较为繁琐复杂（这一点倒是可以通过使用类库来解决）

有人说由于浏览器每次请求都会带上 Cookie，因此 Cookie 还有个缺点是会增加带宽占用，但其实放在今天的网络环境来看，这点占用基本可以忽略不计

总之，如今已经不推荐使用 Cookie 来在浏览器上保存数据，大部分曾经应用 Cookie 的场景，在今天都可以用 LocalStorage 实现更优雅更安全的替代

但是，即使 Cookie 已经不适合用来在浏览器上储存数据，其在某些特定领域，在今天仍然独特的价值

最常见的就是用在广告中，用来跨站标记用户与跟踪用户行为，这样在你访问不同页面时，广告商也能知道是同一个用户在访问，从而实现后续的商品推荐等功能

假设 abc.com 和 xyz.com 都内嵌了淘宝的广告，你会发现即使 abc.com 和 xyz.com 所有者不一致，两个网站上淘宝广告推荐的商品也出奇的一致，这背后是因为淘宝知道是同一个人，分别在 abc.com 和 xyz.com 访问淘宝的广告

这是如何实现的呢？答案是第三方 Cookie

第三方 Cookie

---

之所以有第三方 Cookie 这个称呼，是因为 Cookie 执行同源策略，a.com 和 b.com 各自只能访问自己的 Cookie，无法访问对方或者任何不属于自己的 Cookie

如果在访问 a.com 时，设置了一个 b.com 的 Cookie（比如内嵌 b.com 的页面），那么这个 Cookie 相对于 a.com 而言就是第三方 Cookie

值得一提的是，是同一个 host 下的不同端口倒是可以互相访问 Cookie

这里提一下对第三方 Cookie 而言非常重要的一个特性：Cookie 可以被服务端设置

服务器可以通过 response 的请求头来要求浏览器设置 Cookie

Set-Cookie: userId=123;

浏览器在检测到返回请求的 header 里有 Set-Cookie 请求头后，就会自动设置 Cookie，不需要开发者用 JS 去做额外的操作

这样带来的好处是，当 abc.com 和 xyz.com 想在自己的网页上内嵌淘宝广告时，只需要把淘宝提供的组件放进 HTML 即可，不需要写额外的 JS，也能让淘宝进行跨站定位用户

（这个组件纯属虚构，仅为方便理解）

它是如何工作的呢？

1. 当用户处于 abc.com 时，浏览器会向 taobao.com/some-ads 发起一个 HTTP 请求

2. 当淘宝服务器返回广告内容时，会顺带一个 Set-Cookie 的 HTTP 请求头，告诉浏览器设置一个源为 taobao.com 的 Cookie，里面存上当前用户的 ID 等信息

3. 这个 Cookie 相对于 abc.com 而言就是第三方 Cookie，因为它属于 taobao.com

4. 而当用户访问 xyz.com 时，由于 xyz.com 上也嵌入了淘宝的广告，因此用户的浏览器也会向 taobao.com/some-ads 发起请求

5. 有意思的来了，发请求时，浏览器发现本地已有 taobao.com 的 Cookie（此前访问 abc.com 时设置的），因此，浏览器会将这个 Cookie 发送过去

6. 淘宝服务器根据发过来的 Cookie，发现当前访问 xyz.com 的用户和之前访问 abc.com 的用户是同一个，因此会返回相同的广告

广告商用第三方 Cookie 来跨站定位用户大概就是这么个过程，实际肯定要复杂许多，但基本原理是一致的

总之，关键就是利用了 Cookie 的两个特点

• Cookie 可以被服务器设置

• 浏览器每次请求会自动带上 Cookie

正因为这两个特点，即使 Cookie 在今天看来缺点一大堆，但仍然在部分领域有不可替代的价值

但也是因为这两个特点，导致 Cookie 的安全性相对不高，总之 Cookie 的这个设计放在今天来看，就是一把双刃剑

Cookie 配置

---

服务端要求浏览器建立 Cookie 时，可以在请求头里放一些配置声明，修改 Cookie 的使用特性

SameSite

在前段时间，Chrome 更新 80 版本时，将 Cookie 的跨站策略（SameSite）默认设置为了 Lax，即仅允许同站或者子站访问 Cookie，而老版本是 None，即允许所有跨站 Cookie

这会导致用户访问 xyz.com 时，浏览器默认将不会发送 Cookie 给 taobao.com，导致第三方 Cookie 失效的问题

要解决的话，在返回请求的 header 里将 SameSite 设置为 None 即可

Set-Cookie: userId=123; SameSite=None

Secure, HttpOnly

Cookie 还有两个常用属性 Secure 和 HttpOnly

Set-Cookie: userId=123; SameSite=None; Secure; HttpOnly

其中 Secure 是只允许 Cookie 在 HTTPS 请求中被使用

而 HttpOnly 则用来禁止使用 JS 访问 cookie

ducoment.cookie // 访问被禁止了

这样最大的好处是避免了 XSS 攻击

XSS 攻击

---

比如你在水一个论坛，这个论坛有个 bug：不会对发布内容中的 HTML 标签进行过滤

某一天，一个恶意用户发了个帖子，内容如下：

 

当你访问这条帖子的内容时，浏览器就会执行 <script> 中的代码，导致你的 Cookie 被发送给攻击者，接着攻击者就可以利用你的 Cookie 登录论坛，然后为所欲为了

XSS 攻击在很多情况下，用户甚至不会知道自己被攻击了，比如利用 <img/> 的 src 属性，就可以做到悄无声息的把用户的信息发给攻击者

而当设置了 HttpOnly 后，ducoment.cookie 将获取不到 Cookie，攻击者的代码自然就无法生效了

Cookie 总结

总而言之，Cookie 在今天的适用场景其实比较有限，当你需要在本地储存数据时，由于安全性和储存空间的问题，一般不推荐使用 Cookie，大部分情况下使用 Web Storage 是个更好的选择

Web Storage

===========

在 2014 年年底发布的 HTML5 标准中，新增了一个 Web Storage 的本地储存方案，其包括

• LocalStorage

• SessionStorage

SessionStorage 和 LocalStorage 使用方法基本一致，唯一不同的是，一旦关闭页面，SessionStorage 将会删除数据；因此这里主要以 LocalStorage 为例

LocalStorage 的特点是：

• 使用 Key-Value 形式储存

• 使用很方便

• 大小有 10MB

• Key 和 Value 以字符串形式储存

LocalStorage 的使用非常简单，比如要在本地保存 userId：

localStorage.setItem(‘userId’, ‘123’);

console.log(localStorage.getItem(‘userId’)); // 123

只要用 setItem 保存过一次，哪怕用户关闭了页面，再次打开页面时都可以用 getItem 获取到想要的数据

LocalStorage 一出现，就在许多应用场景彻底替代了 Cookie，大部分需要在浏览器上存数据的场景，都会优先使用 LocalStorage

它和 Cookie 的主要区别是：

• 储存空间更大，使用更方便

• Cookie 可以被服务器设置，而 LocalStorage 只能前端手动操作

• Cookie 的数据会由浏览器自动发给服务器，LocalStorage 需要手动取出来放到请求里面才会发给服务器，因此可以避免 CSRF 攻击

CSRF 攻击

---

假设你在浏览器中登录过某个银行 bank.com，这个银行系统使用 Cookie 来保存你的登录态

接着你访问了一个恶意网站，该网站中有一个表单：

（假设 bank.com/transfer 是用来转账的接口）

当你被诱导点下了提交按钮后：

1. 由于 form 表单提交是可以跨域的，你将会对 bank.com/transfer 发起一次 POST 请求

2. 由于此前你已经登录过 bank.com，浏览器会自动将你的 Cookie 一并发送过去（即使你当前并未处于银行系统的页面）

3. bank.com 收到你的带 Cookie 的请求后，认为你是正常登录了的，导致转账成功进行

4. 最终你损失了一大笔钱

注意即使用 Cookie 配合 HTTPS 请求，CSRF 攻击也无法被避免，因为 HTTPS 请求只是对传输的数据进行了加密，而 CSRF 攻击的特点是，诱导你去访问某个需要你的权限的接口，HTTPS 并不能阻止这种访问

这里的 CSRF 攻击的核心，就是利用了浏览器会自动在所有请求里带上 Cookie 的特性

因此，LocalStorage 比较常见的一个替代 Cookie 的场景就是登录态的保持，比如用 token 的方法加上 HTTPS 请求，就可以很大程度上提高登录的安全性，避免被 CSRF 攻击（但是依然无法完全避免被 XSS 攻击的风险）

大概工作流程就是，用户登录后，从服务器拿到一个 token，然后存进 LocalStorage 里，之后每次请求前都从 LocalStorage 里取出 token，放到请求数据里，服务器就能知道是同一个用户在发起请求了；由于 HTTPS 的存在，也不用担心 token 会被泄露给第三方，因此是很安全的

总结为什么 LocalStorage 在大部分应用场景替代了 Cookie：

• LocalStorage 更好用，更简单，储存空间更多

• LocalStorage 免去了 Cookie 遭受 CSRF 攻击的风险

LocalStorage 的缺点

---

但是，LocalStorage 也不是完美的，它有两个缺点：

• 无法像 Cookie 一样设置过期时间

• 只能存入字符串，无法直接存对象

举个例子，假如你想存一个对象或者非 string 的类型到 LocalStorage：

localStorage.setItem(‘key’, {name: ‘value’});

console.log(localStorage.getItem(‘key’)); // ‘[object, Object]’

localStorage.setItem(‘key’, 1);

console.log(localStorage.getItem(‘key’)); // ‘1’

你会发现，存进去的如果是对象，拿出来就变成了字符串 '[object, object]'，数据丢失了！

存进去的如果是 number，拿出来也变成了 string

要解决这个问题，一般是使用 JSON.stringify() 配合 JSON.parse()

localStorage.setItem(‘key’, JSON.stringify({name: ‘value’}));

console.log(JSON.parse(localStorage.getItem(‘key’))); // {name: ‘value’}

这样，就可以实现对象和非 string 类型的储存了

但是，这么做有一个缺点，那就是 JSON.stringify() 本身是存在一些问题的

const a = JSON.stringify({

a: undefined,

b: function(){},

c: /abc/,

d: new Date()

});

console.log(a) // “{“c”:{},“d”:“2021-02-02T19:40:12.346Z”}”

console.log(JSON.parse(a)) // {c: {}, d: “2021-02-02T19:40:12.346Z”}

如上，JSON.stringify() 无法正确转换 JS 的部分属性

• undefiend

• Function

• RegExp（正则表达式，转换后变成了空对象）

• Date（转换后变成了字符串，而非 Date 类的对象）

其实还有个 Symbol 也无法被转换，但由于 Symbol 本身定义（全局唯一性）就决定了，它不应该被转换，否则即使转换回来，也不会是原来那个 Symbol

Function 也比较特殊，不过要兼容的话，可以先调用 .toString() 转换为字符串储存，需要的时候再 eval 转回来

以及，JSON.stringify() 无法转换循环引用的对象

const a = { key: ‘value’ };

a[‘a’] = a;

JSON.stringify(a);

// Uncaught TypeError: Converting circular structure to JSON

//     --> starting at object with constructor ‘Object’

//     — property ‘a’ closes the circle

//     at JSON.stringify ()

大部分应用中，JSON.stringify() 的这个问题基本上可以忽略，但是一小部分场景还是会导致问题，比如想保存一个正则表达式，一个 Date 对象，这种方法就会出问题

总结

在大部分应用场景下，LocalStorage 已经能完全替代 Cookie，只有类似于广告这种场景，由于 Cookie 可以被服务端设置，Cookie 仍存在不可替代的价值

但是 LocalStorage 并不完美，它只支持 10MB 储存，在一些应用场景还是不够用，并且原生只支持字符串，JSON.stringify() 的解决方案又不够完美，因此很多时候不太适合大量数据和复杂数据的储存

IndexedDB

=========

IndexedDB 的全称是 Indexed Database，从名字中就可以看出，它是一个数据库

IndexedDB 早在 2009 年就有了第一次提案，但其实它和 Web Storage 几乎是同一时间普及到各大浏览器的（没错，就是 2015 年那会，es6 也是那时候）

IndexedDB 是一个正经的数据库，它在问世后替代了原来不正经的 Web SQL 方案，成为了当今唯一运行在浏览器里的数据库

在我看来，IndexedDB 其实更适合当作终极前端本地数据储存方案

相比于 LocalStorage，IndexedDB 的优点是

• 储存量理论上没有上限

• • Chrome 对 IndexedDB 储存空间限制的定义是：硬盘可用空间的三分之一

• 所有操作都是异步的，相比 LocalStorage 同步操作性能更高，尤其是数据量较大时

• 原生支持储存 JS 的对象

• 是个正经的数据库，意味着数据库能干的事它都能干

但是缺点也比较致命：

• 操作非常繁琐

• 本身有一定门槛（需要你懂数据库的概念）

由于提案较早，IndexedDB 的 API 设计其实是比较糟糕的，对于新手而言，光是想连上数据库，并往里面加东西，都需要折腾半天

对于简单的数据储存而言，IndexedDB 的 API 显得太复杂了，再加上其 API 全是异步的，会带来额外的心智负担，远没有 LocalStorage 简单两行代码搞定数据存取来的快

因此，IndexedDB 在今天的使用规模相比 LocalStorage 差远了，即使 IndexedDB 本身的设计其实更适合用来在浏览器上储存数据

总之，如果不考虑 IndexedDB 的操作难度，其作为一个前端本地储存方案其实是接近完美的

简单理解数据库

---

在使用 IndexedDB 前，你首先需要懂基本的数据库概念

这里用 Excel 类比，简单介绍数据库的基本概念，不做太深入的讨论

需要了解四个基本概念，以关系型数据库为例

• 数据库 Database

• 数据表 Table（IndexedDB 中叫 ObjectStore）

• 字段 Field

• 事务 Transaction

（虽然 IndexedDB 算不上关系型数据库，但概念都是相通的）

假设清华和北大各自需要建一个数据库，用来存各自学生与教工的信息，假设命名为

• 清华：thu

• 北大：pku

这样，清北之间的数据就可以相互独立

然后，我们再到数据库里建表

• student 表，储存学生信息

• stuff 表，储存教工信息

数据表（Table）是什么？说白了，就是一个类似于 Excel 表一样的东西

比如 student 表，可以长这样：

image-20210204032958192

上面的 学号、姓名、年龄、专业 就是数据表的字段

当我们想往 student 表添加数据时，就需要按照规定的格式，往表里加数据（关系型数据库的特点，而 IndexedDB 允许不遵守格式）

数据库也给我们提供了方法，当我们知道一个学生的学号（id），就可以在非常短的时间内，在表里成千上万个学生中，快速找到这个学生，并返回他的完整信息

也可以根据 id 定位，对该学生的数据进行修改，或者删除

id 这种每条数据唯一的值，就可以被用来做主键（primary key），主键在表内独一无二，无法添加相同主键的数据

而主键一般会被建立索引，所谓对字段建立索引，就是可以根据这个字段的值，在表里非常快速的找到对应的数据（通常不高于 O(logN)），如果没有索引，那可能就需要遍历整个表（O(N)）

增、删、改、查这些操作，都需要通过事务 Transaction 来完成

• 如果事务中任何一个操作没有成功，整个事务都会回滚

• 在事务完成之前，操作不会影响数据库

• 不同事务之间不能互相影响

举个例子，当你发起一个事务，想利用这个事务添加两个学生，如果第一个学生添加成功，但是第二个学生添加失败，事务就会回滚，第一个学生将根本不会在数据库中出现过

事务在银行转账这种场景非常有用：如果转账中任何一步失败了，整个转账操作就和没发生过一样，不会造成任何影响

在同一个 Excel 文件（数据库）中，我们除了 student 表，还可以有 stuff 表（同一个数据库中有了两个不同的数据表）：

image-20210204033839030

然后，清华和北大各自分一个 Excel 文件，就相当于分了两个数据库

image-20210204034441432

总而言之，不扯数据库各种难理解的概念，我们其实完全可以用 Excel 来类比数据库

• 一个 Excel 文件就是一个 Database

• 一个 Excel（Database）里可以有很多不同表格（数据表 Table）

• 表格的列的名称其实就是字段

上述类比最接近 MySQL 这种关系型数据库，但放在其它一些比较特殊的数据库上可能就不太妥当（比如图数据库）

如果你是新手，用 Excel 类比理解数据库完全没问题，足以使用 IndexedDB 了

虽然说 IndexedDB 使用 key-value 的模式储存数据，但你也完全可以用数据表 Table 的模式来看待它

IndexedDB 的使用

---

使用 IndexedDB 的第一步是打开数据库：

const request = window.indexedDB.open(‘pku’);

上面这个操作打开了名为 pku 的数据库，如果不存在，浏览器会自动创建

然后 request 上有三个事件：

var db; // 全局 IndexedDB 数据库实例

request.onupgradeneeded = function (event) {

db = event.target.result;

console.log(‘version change’);

};

request.onsuccess = function (event) {

db = request.result;

console.log(‘db connected’)l;

};

request.onblocked = function (event) {

console.log(‘db request blocked!’)

}

request.onerror = function (event) {

console.log(‘error!’);

};

IndexedDB 有一个版本（version）的概念，连接数据库时就可以指定版本

最后

面试题千万不要死记，一定要自己理解，用自己的方式表达出来，在这里预祝各位成功拿下自己心仪的offer。

IndexedDB 使用 key-value 的模式储存数据，但你也完全可以用数据表 Table 的模式来看待它

IndexedDB 的使用

---

使用 IndexedDB 的第一步是打开数据库：

const request = window.indexedDB.open(‘pku’);

上面这个操作打开了名为 pku 的数据库，如果不存在，浏览器会自动创建

然后 request 上有三个事件：

var db; // 全局 IndexedDB 数据库实例

request.onupgradeneeded = function (event) {

db = event.target.result;

console.log(‘version change’);

};

request.onsuccess = function (event) {

db = request.result;

console.log(‘db connected’)l;

};

request.onblocked = function (event) {

console.log(‘db request blocked!’)

}

request.onerror = function (event) {

console.log(‘error!’);

};

IndexedDB 有一个版本（version）的概念，连接数据库时就可以指定版本

最后

面试题千万不要死记，一定要自己理解，用自己的方式表达出来，在这里预祝各位成功拿下自己心仪的offer。

[外链图片转存中…(img-5XjA8XIe-1719253693379)]

[外链图片转存中…(img-lb7Vc3rU-1719253693380)]

[外链图片转存中…(img-7s9ITLv5-1719253693380)]

[外链图片转存中…(img-JKTq6ocg-1719253693381)]