浏览器存储方案（Cookie、LocalStorage、SessionStorage）

发布于 2022-06-19 14:48:28 字数 17595 浏览 1219 评论 0

会话

在程序中，会话跟踪是很重要的事情。理论上，一个用户的所有请求操作都应该属于同一个会话，而另一个用户的所有请求操作则应该属于另一个会话，二者不能混淆。例如，用户A在超市购买的任何商品都应该放在A的购物车内，不论是用户A什么时间购买的，这都是属于同一个会话的，不能放入用户B或用户C的购物车内，这不属于同一个会话。

web应用中的会话是指一个客户端浏览器和服务器之间连续发生的一系列请求和响应的过程。
web应用中的会话状态是指web服务器与浏览器在会话过程中产生的状态信息，借助会话状态，服务器能够把属于同一会话中的一系列的请求和响应过程关联起来。

而Web应用程序是使用 HTTP 协议传输数据的。HTTP协议是无状态的协议。一旦数据交换完毕，客户端与服务器端的连接就会关闭，再次交换数据需要建立新的连接。这就意味着服务器无法从连接上跟踪会话。即用户A购买了一件商品放入购物车内，当再次购买商品时服务器已经无法判断该购买行为是属于用户A的会话还是用户B的会话了。要跟踪该会话，必须引入一种机制。

Cookie就是这样的一种机制(在客户端保持)。它可以弥补 HTTP 协议无状态的不足。在 Session 出现之前，基本上所有的网站都采用 Cookie 来跟踪会话。

一、Cookie

首先，很多人会把cookie和文件缓存弄混淆，这两个完全是不一样的东西。唯一的相同之处可能是它们俩都存在硬盘上，而且是存在同一个文件夹下。

文件（资源）缓存请移步这篇文章：#4

由于 HTTP 是一种无状态的协议，服务器单从网络连接上无从知道客户身份。怎么办呢？就给客户端们颁发一个通行证吧，每人一个，无论谁访问都必须携带自己通行证。这样服务器就能从通行证上确认客户身份了。这就是Cookie的工作原理。

Cookie 实际上是一小段的文本信息(纯文本格式，不包含任何可执行的代码)。即 cookie 只包含数据，就其本身而言并不有害。

客户端请求服务器，如果服务器需要记录该用户状态，就使用 response header向客户端浏览器颁发一个Cookie。客户端浏览器会把Cookie保存起来。(web服务器通过在http响应消息头总增加 Set-Cookie 响应头字段将Cookie信息发送给浏览器，浏览器则通过在 http 请求消息中增加 Cookie 请求头字段将 Cookie 回传给web服务器。)当浏览器再请求该网站时，浏览器把请求的网址连同该 Cookie 一同提交给服务器。服务器检查该 Cookie，以此来辨认用户状态。服务器还可以根据需要修改Cookie的内容。

1. Cookie的限制条件

注意：Cookie功能需要浏览器的支持。

如果浏览器不支持Cookie（如大部分手机中的浏览器）或者把Cookie禁用了，Cookie功能就会失效。
不同的浏览器采用不同的方式保存Cookie。IE浏览器会在“C:\Documents and Settings\你的用户名\Cookies”文件夹下以文本文件形式保存，一个文本文件保存一个Cookie。

每个站点最多存放20个Cookie，每个Cookie的大小限制为4KB。

浏览器一般只允许存放300个Cookie，原始规范中限定每个域名下不超过 20 个 cookie，早期的浏览器都遵循该规范，并且在 IE7 中有更近一步的提升。在微软的一次更新中，他们在 IE7 中增加 cookie 的限制数量到 50 个，与此同时 Opera 限定 cookie 数量为 30 个，Safari 和 Chrome 对与每个域名下的 cookie 个数没有限制。

发向服务器的所有 cookie 的最大数量（空间）仍旧维持原始规范中所指出的：4KB。所有超出该限制的 cookie 都会被截掉并且不会发送至服务器。

1. Cookie 的构成

Web 服务器通过发送一个称为 Set-Cookie 的 HTTP 消息头来创建一个 cookie，Set-Cookie 消息头是一个字符串，其格式如下（中括号中的部分是可选的）：

Set-Cookie: value[; expires=date][; domain=domain][; path=path][; secure]
// set cookie: name=value; domain=.mozilla.org; expires=Feb, 13-Mar-2018 11:47:50; path=/; secure

（1）value 部分：通常是一个 name=value 格式的字符串。name: 一个唯一确定cookie的名称，不分大小写，cookie的名字必须是经过URL编码的，一般可以采用某个前缀在加上当前时间的做法，这样的话名称能够确保是唯一的，也比较方便；value：存储在cookie中的字符串值，必须经过被URL编码。

对于可选项部分：紧跟 cookie 值后面的每个选项都以分号和空格分开，每个选择都指定了 cookie 在什么情况下应该被发送至服务器。

通过 Set-Cookie 指定的可选项只会在浏览器端使用，而不会被发送至服务器端(只包含了 cookie 的值，忽略全部设置选项。)。发送至服务器的 cookie 的值与通过 Set-Cookie 指定的值完全一样，不会有进一步的解析或转码操作。如果请求中包含多个 cookie，它们将会被分号和空格分开，例如：

// request header
Cookie: value

// 多个cookie
Cookie: value1; value2; name1=value1

服务器创建 session，将会将 jessionid 写入cookie。第二次请求时，则有了该 cookie。

（2）expires 过期时间选项：指定了 cookie 何时不会再被发送至服务器，随后浏览器将删除该 cookie。该选项的值是一个 Wdy, DD-Mon-YYYY HH:MM:SS GMT 日期格式（GMT格式）的值。

没有设置 expires 选项时，cookie 的生命周期仅限于当前会话中，关闭浏览器意味着这次会话的结束，所以会话 cookie 仅存在于浏览器打开状态之下。这就是为什么为什么当你登录一个 Web 应用时经常会看到一个复选框，询问你是否记住登录信息：如果你勾选了复选框，那么一个 expires 选项会被附加到登录 cookie 中。如果 expires 设置了一个过去的时间点(设置为 0)，那么这个 cookie 会被立即删掉。设置为-1时，代表关闭当前浏览器即失效。

会话cookie：临时的cookie，在内存中。它记录了用户访问站点时的设置和偏好，关闭浏览器，会话cookie就被删除了；
持久化cookie: 存储在硬盘上，（不管浏览器退出，或者电脑重启，持久cookie都存在），持久cookie有过期时间。

（3）domain 选项：指定了 cookie 将要被发送至哪个或哪些域中(对于哪些域是有效的)。默认情况下，domain 会被设置为创建该 cookie 的页面所在的域名，所以当给相同域名发送请求时该 cookie 会被发送至服务器。在上诉例子中就是.Mozilla.org。

Cookie是不可跨域名的。

域名www.google.com颁发的Cookie不会被提交到域名www.baidu.com去。这是由Cookie的隐私安全机制决定的。隐私安全机制能够禁止网站非法获取其他网站的Cookie。

正常情况下，同一个一级域名下的两个二级域名如www.yahoo.com和my.yahoo.com（finance.yahoo.com 等等）也不能交互使用Cookie，因为二者的域名并不严格相同。

如果想所有yahoo.com名下的二级域名都可以使用该Cookie，需要将一个 cookie 的 domain 选项设置为 .yahoo.com。（注意：domain参数必须以点(“.”)开始。）

这样，浏览器会把 domain 的值与请求的域名做一个尾部比较（即从字符串的尾部开始比较），并将匹配的 cookie 发送至服务器。（主域和子域：在主域上设置 cookie 后，子域是可以访问到的）

domain 选项的值必须是发送 Set-Cookie 消息头的主机名的一部分。不合法的 domain 选择将直接被忽略。比如我在 yahoo.com 的域的响应头中设置 domain 为 google.com，因为这会产生安全问题。

延伸：

http://www.a.com:8080
// 其中http是协议，www是二级域名(子域)，a.com是一级域名（主域），8080是端口号。

跨域是指：协议、域名、端口任一不同时。

所以，主域相同子域不同也属于跨域。对于主域相同而子域不同的例子，可以通过设置document.domain的办法来解决。

设置相同的document.domain。在 http://www.a.com/a.html 和 http://script.a.com/b.html 两个文件中分别加上 document.domain = ‘a.com’；
通过 a.html 文件中创建一个 iframe，去控制 iframe 的 contentDocument ，这样两个js文件之间就可以交互了。

另外：某一页面的domain默认等于window.location.hostname。主域名是不带www的域名，例如a.com，主域名前面带前缀的通常都为二级域名或多级域名，例如www.a.com其实是二级域名。domain只能设置为主域名，不可以在b.a.com中将domain设置为c.a.com。

（4）path 选项：指定域中的哪个路径，应该向服务器发送 cookie，/ 表示没有限制。

Set-Cookie:name=Nicholas;path=/blog

在这个例子中，path 选项值会与 /blog，/blogrool 等等相匹配；任何以 /blog 开头的选项都是合法的。需要注意的是，只有在 domain 选项核实完毕之后才会对 path 属性进行比较。path 属性的默认值是发送 Set-Cookie 消息头所对应的 URL 中的 path 部分。

（5）安全标志 secure：指定以后，cookie只有在使用 SSL/HTTPS 连接的时候才可以发送到服务器。该选项只是一个标记而没有值。只有当一个请求通过 SSL 或 HTTPS 创建时，包含 secure 选项的 cookie 才能被发送至服务器。这种 cookie 的内容具有很高的价值，如果以纯文本形式传递很有可能被篡改。

事实上，机密且敏感的信息绝不应该在 cookie 中存储或传输，因为 cookie 的整个机制原本都是不安全的。默认情况下，在 HTTPS 链接上传输的 cookie 都会被自动添加上 secure 选项。

2. Cookie 的分类

2. Cookie 的维护（针对服务端，原理同样适用于客户端）

Cookie 并不提供修改、删除操作。

如果要修改某个Cookie，只需要新建一个同名的Cookie，添加到 response header中覆盖原来的Cookie。
如果要删除某个Cookie，只需要新建一个同名的Cookie，并将有效期设置为0，并添加到response中覆盖原来的Cookie。

注意是0而不是负数。负数代表其他的意义。

注意：修改、删除Cookie时，新建的Cookie除value、expires之外的所有属性，例如name、path、domain等，都要与原Cookie完全一样。否则，浏览器将视为两个不同的Cookie不予覆盖，导致修改、删除失败。

下面说一下 expires：（为什么修改、删除Cookie时，name、path、domain必须相同，expires不需要？）

要改变一个 cookie 的失效日期，你必须指定同样的组合（ame、path、domain必须相同）。当改变一个 cookie 的值时，你不必每次都设置失效日期，因为它不是 cookie 标识信息的组成部分。例如:

Set-Cookie:name=Mike;expires=Sat,03 May 2025 17:44:22 GMT

我想要改变这个 cookie 的值时，我只需要使用它的名字(因为没有path、domain可选项)：

Set-Cookie:name=Matt

cookie 的失效日期并没有改变，因为 cookie 的标识符是相同的。实际上，只有你手工的改变 cookie 的失效日期，否则其失效日期不会改变。这意味着在同一个会话中，一个会话 cookie 可以变成一个持久化 cookie（一个可以在多个会话中存在的），反之则不可。为了要将一个持久化 cookie 变为一个会话 cookie，你必须删除这个持久化 cookie，这只要设置它的失效日期为过去某个时间之后再创建一个同名的会话 cookie 就可以实现。

需要记得的是失效日期是以浏览器运行的电脑上的系统时间为基准进行核实的。没有任何办法来来验证这个系统时间是否和服务器的时间同步，所以当服务器时间和浏览器所处系统时间存在差异时这样的设置会出现错误。

3. JavaScript 中的 cookie

在 JavaScript 中通过 document.cookie 属性，你可以创建、维护和删除 cookie。创建 cookie 时该属性等同于 Set-Cookie 消息头，而在读取 cookie 时则等同于 Cookie 消息头。在创建一个 cookie 时，你需要使用和 Set-Cookie 期望格式相同的字符串：

设置 document.cookie 属性的值并不会删除存储在页面中的所有 cookie。它只简单的创建或修改字符串中指定的 cookie。下次发送一个请求到服务器时，通过 document.cookie 设置的 cookie 会和其它通过 Set-Cookie 消息头设置的 cookie 一并发送至服务器。这些 cookie 并没有什么明确的不同之处。

/**
* description：Cookie的建立
* name, value 必传
*/
function setCookie(name,value,expiredate,domain,path,secure){
    var cookieText=escape(name)+"="+escape(value);
    if(expiredate){
        var exdate=new Date();
        exdate.setDate(exdate.getDate()+expiredate);
        cookieText+=";expires="+exdate.toGMTString();
    }
    if(domain){
        cookieText+=";domain="+domain;
    }
    if(path){
        cookieText+=";path="+path;
    }
    if(secure){
        cookieText+=";secure";
    }
    document.cookie=cookieText;
}

/**
* description：Cookie的查询
*/
function getCookie(name){
    var cookieName=encodeURIComponent(name)+"=",
    cookieStart=document.cookie.indexOf(cookieName),
    cookieValue=null;
    if(cookieStart>-1){
        var cookieEnd=document.cookie.indexOf(";",cookieStart);
        if(cookieEnd==-1){
            cookieEnd=document.cookie.Length;
        }
        cookieValue=decodeURIComponent(document.cookie.substring(cookieStart+document.cookie.length,cookieEnd));
    }
    return cookieValue;
}

// 重新定义cookie，把时间调为过去，原先的cookie就会失效，value也被设置为空值，这样就可以删除一个cookie。
function deCookie(name,value,expiredate,domain,path,secure){
    this.setCookie(name,"",new Date(0),domain,path,secure);
}

参考文章

JavaScript跨域总结与解决办法

4. HTTP-Only cookies

微软的 IE6 SP1 在 cookie 中引入了一个新的选项：HTTP-only，HTTP-Only 背后的意思是告之浏览器该 cookie 绝不能通过 JavaScript 的 document.cookie 属性访问。设计该特征意在提供一个安全措施来帮助阻止通过 JavaScript 发起的跨站脚本攻击 (XSS) 窃取 cookie 的行为。今天 Firefox2.0.0.5+、Opera9.5+、Chrome 都支持 HTTP-Only cookie。3.2 版本的 Safari 仍不支持。

要创建一个 HTTP-Only cookie，只要向你的 cookie 中添加一个 HTTP-Only 标记即可：

Set-Cookie: name=Nicholas; HttpOnly

二、Session

cookie可以用来保存信息，也可以跟踪会话。例如，当我们登录网站勾选保存用户名和密码的时候，用户名和密码的cookie就会被保存到硬盘中；再比如网页的背景颜色也是通过cookie 保存到客户端的，这样登录之后浏览器直接就可以拿到相应的偏好设置。（这里cookie技术是在在客户端使用的）

cookie也可以跟踪会话（这里cookie技术是在在服务端使用的），比如某些网站中网页有不同的访问权限，有只能登录的用户访问的网页或者用户级别不同不能访问的，但是http请求是无状态的，每次访问服务端是不知道是否是登录用户，很自然的想到在http请求报文中加入登录标识就可以了，这个登录标识就可以是cookie，这样的cookie服务端要保存有所有登录用户的cookie，这样请求报文来了之后拿到登录标识cookie，在服务端进行比较就可以了。再比如购物网站，多次点击添加商品到购物车客户端很容易知道哪些物品在购物车中，但是服务端怎么知道每次添加的物品放到哪个登录用户的购物车中呢？也需要请求报文中带着cookie才行。这些cookie都是为了跟踪会话用的。

所以 cookie 客户端有，服务端也有，并且服务端有全部的会话cookie。

后面衍生出 session 技术, session 技术是要使用到 cookie 的，之所以出现 session 技术，主要是为了安全(一些重要敏感的用户信息存储在客户端，还可能会是持久化的，不安全)。

cookie 可以让服务端程序跟踪每个客户端的访问，但是每次客户端的访问都必须传回这些 Cookie，如果 Cookie 很多，这无形地增加了客户端与服务端的数据传输量，

而 Session 的出现正是为了解决这个问题。同一个客户端每次和服务端交互时，不需要每次都传回所有的 Cookie 值，而是只要传回一个 ID，这个 ID 是客户端第一次访问服务器的时候生成的，

而且每个客户端是唯一的。这样每个客户端就有了一个唯一的 ID，客户端只要传回这个 ID 就行了，这个 ID 通常是 NANE 为 JSESIONID 的一个 Cookie。

1. 简介

Session 机制：每次客户端发送请求，服务端都检查是否含有sessionId。如果有，则根据 sessionId 检索出 session 并处理；如果没有，则创建一个session，并绑定一个不重复的sessionId。

Session 是由应用服务器维持的一个服务器端的存储空间（相应的也增加了服务器的存储压力。），用户在连接服务器时，会由服务器生成一个唯一的 SessionID（其值最终会有客户端保存在 JSESSIONID中，JSESSIONID = xxxxxxx），用该 SessionID 为标识符来存取服务器端的Session 存储空间。（即发到客户端的只有Session id， Session 内容会保存在服务器中）

通过 SessionID 来区分不同的客户, session 是以 cookie 或 URL 重写为基础的，默认使用 cookie 来实现。

系统会创造一个名为 JSESSIONID 的输出cookie，我们叫做 session cookie, 以区别 persistent cookies, 也就是我们通常所说的 cookie, 注意 session cookie 是存储于浏览器内存中的，并不是写到硬盘上的(类似一种会话 cookie )，这也就是我们刚才看到的 JSESSIONID。（服务端执行session机制时候会生成session的id值，这个id值会发送给客户端，客户端每次请求都会把这个id值放到http请求的头部发送给服务端，而这个id值在客户端会保存下来，保存的容器就是cookie）

而 SessionID 这一数据则是保存到客户端，用 Cookie 保存的，用户提交页面时，会将这一 SessionID 提交到服务器端，来存取 Session 数据。（每次请求在请求头中的Cookie 字段中，携带jsessionid信息，由服务端校验客户端的多个请求是否是隶属于一个 Session。）所以一旦客户端禁用 Cookie ，那么 Session 也会失效。

如果客户端 Cookie 禁用，则服务器可以自动通过重写 URL 的方式（（我们就可以在地址栏看到 sessionid=KWJHUG6JJM65HS2K6 之类的字符串））来保存Session的值，并且这个过程对程序员透明。

2. session 特点

由于persistent cookie只是存在于客户端硬盘上的一段文本（通常是加密的），而且可能会遭到cookie欺骗以及针对cookie的跨站脚本攻击，所以session cookie更为安全。

关闭浏览器session cookie就会失效

Session Cookie为服务器自动生成的，它的maxAge属性一般为-1，表示仅当前浏览器内有效。即session cookie针对某一次会话而言，会话结束session cookie也就随着消失了。

每次请求都会生成一个新的 sessionid。（通常session cookie是不能跨窗口使用的/各浏览器窗口间不共享）。

同一机器的两个浏览器窗口访问服务器时，会生成两个不同的Session。但是由浏览器窗口内的链接、脚本等打开的新窗口（也就是说不是双击桌面浏览器图标等打开的窗口）除外。这类子窗口会共享父窗口的Cookie，因此会共享一个Session。

当你新开了一个浏览器窗口进入相同页面时，系统会赋予你一个新的 sessionid。若要共享信息。可以先把sessionid保存在persistent cookie中，然后在新窗口中读出来，就可以得到上一个窗口SessionID了，这样通过session cookie和persistent cookie的结合我们就实现了跨窗口的session tracking（会话跟踪）。

session 不会因为浏览器的关闭而删除

Session (存在于服务端)什么时候消失（删除）：
1）Session超时：超时指的是连续一定时间服务器没有收到该 Session 所对应客户端的请求，并且这个时间超过了服务器设置的Session超时的最大时间。（为防止内存溢出，服务器会把长时间内没有活跃的Session从内存删除。这个时间就是Session的超时时间。）
2）程序调用HttpSession.invalidate()
3）服务器关闭或服务停止

即关闭浏览器并不销毁session ，只是 session cookie会失效（上述三种情况session 才会被销毁）。只是打开新页面或提交新请求时, 获得是一个新的session，而找不到原来的SESSION。

每个session都有个session id, 如果新的页面或新的请求附带着原来的SESSION ID，
那么就会找到之前的SESSION。

3. Session 与 cookie 的区别以及各自的优缺点

cookie 保存在客户端，session保存在服务器端（安全性更高）;
cookie 可以跟踪会话，也可以保存用户喜好或者保存用户名密码，session 用来跟踪会话。
session能支持任何类型的对象(session中可含有多个对象)；cookie 只能保存字符串对象，不能保存对象类型；
cookie需要客户端浏览器的支持：客户端可以不支持，浏览器用户可能会禁用 Cookie；session 可以用url重写的方式；

cookie和session的方案虽然分别属于客户端和服务端，但是服务端的 session 的实现对客户端的 cookie 有依赖关系的。

使用cookie的缺点：

cookie 可以被用户禁止；
cookie 不安全(对于敏感数据，需要加密)；
cookie 只能保存少量的数据(大约是4k)，cookie的数量也有限制(大约是几百个)，不同浏览器设置不一样；
cookie 只能保存字符串；
IE老版本浏览器会有 50 个限制，超出会被新的 Cookie 替换；
如果域名设置不当，所有请求都会带上 Cookie 信息，包括图片、CSS 文件等，造成不必要的流量浪费；
Cookie 的读写性能非常非常的差；

使用session的缺点

一般是寄生在Cookie下的，当Cookie被禁止，Session也被禁止；
当用户访问量很大时，对服务器压力大（如果Session内容过于复杂，当大量客户访问服务器时还可能会导致内存溢出。）；

三、Token（存储在客户端。流程跟session类似）

Token 是用户的验证方式,最简单的 token 组成：uid(用户唯一的身份标识)、time(当前时间的时间戳)、sign(签名，由 token 的前几位+盐以哈希算法压缩成一定长的十六进制字符串，可以防止恶意第三方拼接 token 请求服务器)。

使用基于 Token 的身份验证方法，在服务端不需要存储用户的登录记录。

Token 优势

Token 完全由应用管理，所以它可以避开同源策略
Token 可以避免 CSRF 攻击
Token 可以是无状态的，可以在多个服务间共享

Token与Session的区别

作为身份认证 token安全性比session好，因为每个请求都有签名还能防止监听以及重放攻击

Session 是一种HTTP存储机制，目的是为无状态的HTTP提供的持久机制。Session 认证只是简单的把User 信息存储到Session 里，因为SID 的不可预测性，暂且认为是安全的。这是一种认证手段。但是如果有了某个User的SID,就相当于拥有该User的全部权利.SID不应该共享给其他网站或第三方.

Token,如果指的是OAuth Token 或类似的机制的话，提供的是认证和授权，认证是针对用户，授权是针对App。其目的是让某App有权利访问某用户的信息。这里的 Token是唯一的。不可以转移到其它 App上，也不可以转到其它用户上。

前端性能优化中cookie优化方案：

1、去除没有必要的cookie，如果网页不需要cookie就完全禁掉。
2、将cookie的大小减到最小（由于cookie在访问对应域名下的资源时都会通过HTTP请求发送到服务器，因此，减小cookie的大小，能减小HTTP请求报文的大小，提高响应速度）
3、设置合适的过期时间，较长的过期时间可以提高响应速度。
4、通过使用不同的domain减少cookie的使用。
cookie在访问对应域名下的资源时都会通过HTTP请求发送到服务器，但在访问一些资源，如js，css和图片时，大多数情况下cookie是多余的，可以使用不同的domain来存储这些静态资源，这样访问这些资源时就不会发送多余的cookie，从而提高响应速度。

LocalStorage

除非被清除，否则永久保存。存放数据大小:一般为 5MB

SessionStorage

sessionStorage 与 localStorage 的接口类似，但保存数据的生命周期与 localStorage 不同。做过后端开发的同学应该知道 Session 这个词的意思，直译过来是“会话”。而 sessionStorage 是一个前端的概念，它只是可以将一部分数据在当前会话中保存下来，刷新页面数据依旧存在。但当页面关闭后，sessionStorage 中的数据就会被清空。

存放数据大小:一般为5MB

LocalStorage 和 SessionStorage 的同源策略

不同浏览器无法共享localStorage和sessionStorage中的信息。
同一浏览器的相同域名和端口的不同页面间可以共享相同的 localStorage；但是同一浏览器的相同域名和端口的不同页面间无法共享sessionStorage的信息。这里需要注意的是，页面仅指顶级窗口，如果一个页面包含多个iframe且他们属于同源页面，那么他们之间是可以共享sessionStorage的。在实际开发过程中，遇到的最多的问题就是localStorage的同源策略问题。

LocalStorage 和 SessionStorage 的用途

localStorage 可以接替 Cookie 管理购物车的工作，同时也能胜任其他一些工作。比如HTML5游戏通常会产生一些本地数据，localStorage 也是非常适用的。如果遇到一些内容特别多的表单，为了优化用户体验，我们可能要把表单页面拆分成多个子页面，然后按步骤引导用户填写。这时候 sessionStorage 的作用就发挥出来了。

不是什么数据都适合放在 Cookie、localStorage 和 sessionStorage 中的。使用它们的时候，需要时刻注意是否有代码存在 XSS 注入的风险。因为只要打开控制台，你就随意修改它们的值，也就是说如果你的网站中有 XSS 的风险，它们就能对你的 localStorage 肆意妄为。所以千万不要用它们存储你系统中的敏感数据。