Cookie 和 Storage API 区别与详解

Posted 2023-03-09

参考技术A

它们都是浏览器数据存储的方案，是用于解决 数据持久化 的问题。除此之外，数据也可以存储在内存中（比如挂载到 window 等全局对象下），但这种方式每当页面刷新就会丢失。

下面分别从几个方面，详细地介绍 Cookie 、 sessionStorage 、 localStorage 的区别。

请注意，其中 Cookie 的空间大小指的是 name 、 value 以及 = 号。

另外，这三个不同浏览器下可能会有细微的差异，可忽略。

下表为网上收集（非当前实测结论），看一眼知道有限制这回事就好。

鉴于各浏览器对 Cookie 的空间、数量限制不完全相同，为了较好地兼容，建议如下：

没错，面试官问到这么说吧，应该就 OK 了。

另外，与超出空间限制不同的是，超出数量限制之后，是可以继续添加 Cookie 的，但不同浏览器有不同的策略：一些是替换掉最先（老）的 Cookie ，有些则是随机替换。作简单了解就好，一般项目不会设那么多的，而且 Cookie 过期浏览器是会自动清除的。

这块内容比较多...

铺垫 - 了解同源和同站的区别

区别如下：

铺垫 - 顶级域名和二级域名的认知

关于顶级域名、二级域名，也有很多认知问题。

在国内，很多资料认为，顶级域和一级域是分开的。比如 .baidu.com ，如果按照这种方式划分，那么 .com 是顶级域名， .baidu.com 就是一级域名。好像阿里云就是这样定义的。

而我更偏向于认为， .baidu.com 属于二级域名。不用过分纠结，在团队内统一即可。

eTLD （Top-Level Domains）表示有效顶级域名，那么 eTLD + 1 就表示二级域名。例如：

其中 eTLD 是 .com.cn ，那么 eTLD + 1 就是 .example.com.cn 。关于 eTLD 更多请看 这里 。

铺垫 - 区分同源和同站

先看下，完整的 URL（网址）构成如下：

简单来说，只要二级域名相同，就属于同站。同源则要求更严格。因此同源一定同站，反之则不一定。

以下例子，同站，但不同源。

正题 - 三者的作用域

理解这些很重要，为什么这么说呢？

拓展 - 作用域引发的问题

很多公司，不是每个 Web 项目对应一个三级域名。

这些都很常见，那么问题来了。它们很多都是同源、同站的。假设按小项目划分场景，我在 a 项目中设置了一个 sessionStorage 会话级缓存，那么当前从 a 项目跳转至 b 项目时， b 是可以获取到 a 项目的所有 sessionStorage 的，反之也成立。如果 a 和 b 项目中某个 sessionStorage 的 key 不小心设置成相同的话，那很可能就会影响到对方。 localStorage 同理。至于 Cookie 的话，由于它的空间限制最大只允许 4K，因此不适宜存过多数据，一般会存一些像鉴权信息等比较多。同个公司，业务的用户鉴权等是相似的，所以 Cookie 的访问机制也不会有太大的影响。

针对这些问题，建议是非必要的话，将数据存在内存中，比如用 Vuex、Redux、MobX 等状态管理工具来维护应用的状态。一是信息更不容易暴露，而是可以减少 IO 的读写。但是，这样的话，就要解决数据持久化的问题，因为在内存中的话，只要刷新页面就会丢失。怎么解决？

以 Redux 为例，在创建 Store 时，是可以传入一个初始状态的，它的值取下面这个会话缓存即可。只要监听到状态发生变化变化，并设置或更新 sessionStorage 级别的缓存，将状态缓存起来即可。比如：

注意 - sessionStorage 鲜为人知的点（冷门）

下面例子，均在同源情况下。假设有两个同源页面： A 页面、B 页面对应 URL 为 page_a_url 、 page_b_url 。

示例一：

示例二：将上述第二步改成下面这样：

结果又是什么呢？直接看下结果：

结论：

总结 - 作用域

sessionStorage 和 localStorage 不会主动参与与服务器的通信。

Cookie 是保存在浏览器上的一小型文本文件。在每次与服务器的通信中都会携带在 HTTP 请求头之中。

Q1：storage 事件的迷惑行为

首先，注册 storage 事件监听器，它 只能 监听 其他同源页面 的缓存 发生改变 时，它才会被触发。

得出几个结论：

Q2：当 localStorage 超过 5M 的空间限制之后，若再次 setItem 会怎样？

答案显而易见，这次 setItem() 将会失败，且会抛出错误。针对这种情况，可以做一些处理，比如清空再重新记录等...

Q3：在 Safari 无痕模式下，对 sessionStorage 操作可能会抛出异常

请看这个帖子： html5 localStorage error with Safari: "QUOTA_EXCEEDED_ERR: DOM Exception 22: An attempt was made to add something to storage that exceeded the quota."

Q4：sessionStorage 在 iframe 的问题

前面提到顶级窗口和 iframe 窗口的页面都是同源的情况下，sessionStorage 是可共享的。但不完全是，比如受 iframe 的 sandbox 属性影响，分为两种情况：

假设两个页面同源；情况一 sessionStorage 不共享，在 iframe 中是一个全新的 sessionStorage 对象。情况二则共享 sessionStorage 。

web storage和cookie的区别

Web Storage的概念和cookie相似，区别是它是为了更大容量存储设计的。Cookie的大小是受限的，并且每次你请求一个新的页面的时候Cookie都会被发送过去，这样无形中浪费了带宽，另外cookie还需要指定作用域，不可以跨域调用。
除此之外，Web Storage拥有setItem,getItem,removeItem,clear等方法，不像cookie需要前端开发者自己封装setCookie，getCookie。但是Cookie也是不可以或缺的：Cookie的作用是与服务器进行交互，作为HTTP规范的一部分而存在 ，而Web Storage仅仅是为了在本地“存储”数据而生。