关于浏览器的Cookie与Storage的细枝末节

开始

数据离不开储存，他可以持久的存放，时刻等待下一次被读取。在浏览器端，同样拥有几种数据存储的能力，cookie、localStorage、sessionStorage、IndexedDB，有了储存数据的能力，可以将大量数据保存在浏览器端，减少后端请求压力，可以直接从客户端直接获取。让无状态的Http请求能够拥有不同的身份、让浏览器能够记住你上次输入的账号密码、记住你的登陆状态、让购物车能够装下你所有的喜欢、让推荐引擎能够清楚的知道你看过什么搜过什么...

Cookie

常常使用Cookie来保存用户token，因为Cookie会附着在每次Http请求的请求头上，这样后台就会知道是哪个用户进行的操作。

设置方式：

1. 响应头中使用Set-Cookie来设置浏览器的Cookie
2. 在浏览器端使用js设置

document.cookie="token=XXXXXX"

读取方式：

1. document.cookie
2. 后台解析请求头

特点：

1. 最大4KB
2. 每次随着Http请求头
3. 有过期时间

LocalStorage

过大的Cookie多少会造成不必要的性能损失，毕竟不是所有的缓存都需要随着Http请求一同发送。localStorage的优势改变了cookie的绝对地位，KV、容量更大、不会过期。

特点：

1. 最大5MB
2. 不会随着Http一同发送
3. 不存在过期时间
4. api更优雅，键值对
5. 同步读写

使用方式：
localStorage存在于window对象下，浏览器环境下可以直接调用：

localStorage.setItem('key', 'value')

const value = localStorage.getItem('key')

我们可以认为浏览器的缓存就是把数据直接保存到一个文件中，而每次读写都是对文件的IO。localStorage的读写函数都是同步函数，会阻塞JS主进程。

在实际业务中会遇到需要localStorage内数据过期的需求，我们则需要自己封装一个保存、校验过期的方法即可：将key、value、过期时间保存为对象，使用JSON.stringify转换为String进行保存，读取时恢复为对象后再校验是否过期。

SessionStorage

熟悉后端的同学对session会非常了解，作为会话级储存经常使用在用户登陆状态的保存上。原理是后端创建一个hash（sessionid），借助Cookie的方式保存到登陆用户的浏览器端，浏览器关闭则session失效，相当于在Cookie基础上服务端上封装的一套身份验证逻辑。

与服务端不同的是，浏览器端的sessionStorage的作用域只在当前浏览器窗口（TAB）。即使同一个浏览器打开多个窗口，他们之间的sessionStorage也是彼此隔离、独立的。

sessionStorage与localStorage相似，只是在作用域、生命周期上有所差异。

特点：

1. 最大5MB
2. 不会随着Http一同发送
3. api更优雅，键值对
4. 同步读写
5. tab关闭则过期
6. 作用域仅在当前tab内

sessionStorage常用来保存登陆用户信息，关闭页面时就会自动删除。

IndexedDB

浏览器内置的非关系型数据库，NoSQL小型数据库，同样为KV方式储存，拥有事务、异步读写、大容量等特点，因为日常使用较少这里就不再解释。

作为面试题拔高题，大家有简单了解就行。

总结

以上3种储存方式都遵循浏览器的同源策略，而且在浏览器端一切都为明文显示，重要数据需要进行加密处理。

关于储存，我们经常会讨论四个重点：

1. 作用域
2. 存在哪
3. 存多少
4. 存多久

按着这四个重点走，就会对浏览器的缓存有很深的印象。

0ABA2E28F9B40183B24F5AFE1C598185.jpg