1. 缓存分类
- 服务器端缓存（CDN缓存）；
- 客户端缓存（浏览器缓存）；
2. 浏览器缓存
2.1. 强缓存
浏览器在加载某个资源时，先根据这个资源的一些http header判断它是否命中强缓存，如果命中，浏览器直接从自己的缓存中读取资源，不会发送请求到服务器。比如浏览器在加载某个css文件所在的网页时，发现这个css文件的缓存配置命中了强缓存，浏览器就直接从缓存中加载这个css文件，连请求都不会发送到网页所在的服务器。
2.2. 协商缓存
当强缓存没有命中的时候，浏览器一定会发送一个请求到服务器，服务器依据资源的另外一些HTTP header验证这个资源是否命中协商缓存。
1）命中协商缓存：服务器返回(304)，且不会携带请求资源的数据，而是告诉浏览器可以直接从自己的缓存中加载所请求资源，于是浏览器又从自己的缓存中去加载资源；
2）未命中协商缓存：服务器将资源返回客户端(200)，并更新本地缓存数据。
2.3. 协商缓存与强缓存的区别
强缓存不发送请求到服务器，协商缓存会发送请求到服务器。
2.4. 缓存设置方法
2.4.1 HTML Meta标签控制缓存（非HTTP协议定义）
<META HTTP-EQUIV="Pragma" CONTENT="no-cache">
上述代码的作用是告诉浏览器当前页面不被缓存，每次访问都需要去服务器拉取数据，这种方法使用上很简单，但只有部分浏览器可以支持，而且有缓存代理的服务器都不支持，因为代理不解析HTML内容本身。
2.4.2. HTTP头信息控制缓存
HTTP头信息控制缓存是通过Expires(强缓存)、Cache-control(强缓存)、Last-Modified/If-Modified-Since(协商缓存)、Etag/If-None-Match(协商缓存)实现.
2.4.2.1. Expires
是Http1.0提出的一个表示资源过期时间的header，它描述的是一个绝对时间，由服务器返回，用GMT格式的字符串表示，如：
Expires：Thu,31 Dec 2016 23:55:55 GMT
读取缓存数据条件：缓存过期时间（服务器返回的）<当前时间（客户端当前时间）；
缺点：Expires是较老的强缓存管理header，由于它是服务器返回的一个绝对时间，因此如果客户端的时间与服务器的时间相差很大（比如时钟不同步，或者跨时区），那么误差就较大，所以在HTTP1.1版本开始，使用 Cache-Control: max-age=x 代替；
2.4.2.2. Cache-Control
Cache-Control：描述的是一个相对时间，在进行缓存命中的时候，都是利用客户端时间进行判断，所以相比较Expires，Cache-Control的缓存管理更加有效，安全一些。
读取缓存的数据条件：上次缓存时间（客户端的）+max-age<当前时间（客户端的）；
Cache-Control值：
1）public：指示响应可被任何缓存区缓存；
2）private：指示对于单个用户的整个或部分响应消息，不能被共享缓存处理，这允许服务器仅仅描述当前用户的部分响应消息，此响应消息对于其他用户的请求无效；
3）no-cache：请求或响应消息不能缓存，该选项并不是说可以设置“不缓存”，而是需要和服务器确认；
4）no-store：在请求消息中发送将使得请求和响应消息都不使用缓存，完全存不下来；
5）max-age：指示客户机可以接收生存期不大于指定时间，以秒为单位的响应；
注意：在response header中，Expires和Cache-Control同时存在时，Cache-Control的优先级高于Expires，这两个header可以只启用一个，也可以同时启用。
2.4.2.3. Last-Modified/If-Modified-Since
Last-Modified：需要配合 Cache-Control 使用，Last-Modified 标志某个响应资源的最后修改时间；
If-Modified-Since：当资源过期时（例如Expires强缓存失效），发现资源具有 Last-Modified 声明，则再次向web服务器发送请求时带上 If-Modified-Since，表示请求时间，web服务器收到请求后发现有头 If-Modified-Since，则与被请求资源的最后修改时间进行比对，若最后修改时间较新，说明资源被改动过，则响应整个资源内容（写在响应消息包体内），并返回200；若最后修改时间较旧，说明资源无新修改，则响应HTTP 304（无需包体，节省流量），告知浏览器继续使用所保存的缓存；
缺点：Last-Modified标注的最后修改时间只能精确到秒级，如果某些文件在1秒钟以内被修改多次的话，它将不能准确标注文件的修改时间（无法及时更新文件）；如果某些文件会被定期生成，当有时内容并没有任何变化，但Last-Modified却被改变了，导致文件没法使用缓存，有可能存在服务器没有准确获取文件修改时间，或者与代理服务器时间不一致等情形(无法使用缓存)；
2.4.2.4. Etag/If-None-Match
也需要配合Cache-Control使用。
Etag：web服务器响应请求时，告诉浏览器当前资源在服务器的唯一标识(生成规则由服务器决定)；
If-None-Match：当资源过期时(使用Cache-Control标识的max-age)，发现资源具有Etag声明，则再次向web服务器请求时带上头 If-None-Match(Etag的值)，web服务器收到请求后发现有头 If-None-Match 则与被请求资源的相应校验串进行比对，然后决定返回200或304，Etag是服务器自动生成或由开发者生成的对应资源在服务器端的唯一标识符，能够更加准确的控制缓存，Last-Modified 与 Etag 一起使用时，服务器会优先验证Etag。
2.4.2.5. 浏览器缓存过程
状态码304：如果客户端发送了一个带条件的 GET 请求且该请求已被允许，而文档的内容(自上次访问以来或者根据请求的条件)并没有改变，则服务器应当返回304状态码，简单的表达就是：客户端已经执行了GET，但文件未变化。
3. 服务器端缓存
3.1. CDN缓存
CDN(Content Delivery Network内容分发网络)：属于Cache服务器的一种，其目的是通过现在的Internet中增加一层新的网络架构，将网站的内容发布到最接近用户的网络“边缘”，即通过调试系统将用户的请求路由引导到离用户接入网络最近或者访问效果最佳的缓存服务器上，由该缓存服务器为用户提供内容服务。相对于直接访问源站，这种方式缩短了用户和内容之间的网络距离，从而达到加速的效果；使用户可以就近取得所需的内容，解决Internet网络拥塞状况，提高用户访问网站的响应速度，从技术上全面解决由于网络带宽小、用户访问量大、网点分布不均等原因，解决用户访问网站的响应速度慢的根本原因。
访问过程：
1）用户向浏览器提供要访问的域名；
2）浏览器调用域名解析库对域名进行解析，由于CDN对域名解析过程进行了调整，所以解析函数库一般得到的是该域名对应的CNAME记录，为了得到实际IP地址，浏览器需要再次对获得的CNAME域名进行解析以得到实际IP地址；在此过程中，使用的全局负载均衡DNS解析，如根据地理位置信息解析对应的IP地址，使用户能就近访问，此次解析得到的是CDN缓存服务器的IP地址；
3）浏览器得到实际IP地址，向缓存服务器发出访问请求；
4）若请求文件并未修改，返回304(充当服务器的角色)，若当前文件已经过期，则缓存服务器根据提供的要访问的域名，通过Cache内部专用DNS解析得到此域名的实际IP地址，再由缓存服务器向此实际IP地址提交访问请求；
5）缓存服务器从实际IP地址得到内容以后，一方面在本地进行保存，以备以后使用，另一方面把获取的数据返回给客户端，完成数据服务过程；
6）客户端得到由缓存服务器返回的数据以后显示出来并完成整个数据请求过程；
4. cookie与session
4.1. cookie
cookie：本地缓存机制，正统的cookie分发是通过扩展HTTP协议来实现的，服务器通过在 HTTP的响应头中添加一行特殊的指示以提示浏览器按照指示生成相应的cookie；用户每请求一次服务器数据，cookie则会随着这些请求发送到服务器，服务器脚本语言如PHP等能够处理cookie发送的数据，可以说是非常方便的，当然前端也是可以生成cookie的，用js对cookie的操作相当繁琐，浏览器只提供 document.cookie 这样一个对象，对cookie的赋值，获取都比较麻烦，而在PHP中可以通过setcookie()来设置cookie，通过$_COOKIE这个超全局数组来获取cookie；
cookie的内容：主要包括：名字，值，过期时间，路径和域，路径与域一起构成cookie的作用范围，路径和域就是对应的域名，a网站的cookie自然不能给b用；若不设置过期时间，则表示这个cookie的生命期为浏览器会话期间，关闭浏览器窗口，cookie就消失，这种生命期为浏览器会话期的cookie被称为会话cookie，会话cookie一般不存储在硬盘上而是保存在内存里，当然这种行为并不是规范规定的，若设置了过期时间，浏览器就会把cookie保存在硬盘上，关闭后再次打开浏览器，这些cookie仍然有效直到超过设定的过期时间，存储在硬盘上的cookie可以在不同的浏览器进程间共享，比如两个IE窗口，而对于保存在内存里的cookie，不同的浏览器有不同的处理方式。
4.2. session
session：是一种服务器端的机制，服务器使用一种类似于散列表的结构来保存信息，当程序需要为某个客户端的请求创建一个session标识（称为session_id）,如果已经包含则说明此前为此客户端创建过session，服务器就按照session_id把这个session检索出来使用，检索不到会新建一个；如果客户端请求不包含session_id，则为此客户端创建一个session并且生成一个与此session相关联的session_id，session_id的值应该是一个既不会重复，又不容易被找到规律以仿造的字符串，这个session_id将在本次响应中返回给客户端保存，同一客户端启动二次session_start的话，session_id是不一样的，保存这个session_id的方式可以采用cookie，这样在交互过程中浏览器可以自动的按照规则把这个标识发送给服务器，一般这个cookie的名字都是类似于session_id，但cookie可以被人为的禁止，则必须有其他机制以便在cookie被禁止时仍然能够把session_id传递回服务器，经常使用的一种技术叫做URL重写，就是把session_id直接附加在URL路径的后面，比如：http://damonare.cn?sessionid=123456，还有一种技术叫做表单隐藏字段，就是服务器会自动修改表单，添加一个隐藏字段，以便在表单提交时能够把session_id传递回服务器。
session为什么出现：HTTP本身是无状态协议，即服务器无法识别两个先后发送到服务器端的请求是否由同一个客户端发起，因此对于每一个请求都要进行身份认证，而session是用来简化这个认证过程的。
4.3. cookie和session的区别
1）cookie数据存放在客户的浏览器上，session数据存放在服务器上；
2）cookie不是很安全，别人可以分析存放在本地的cookie并进行欺骗，考虑到安全应当使用session，cookie是以明文形式存放在客户端的，安全性低，可以通过一个加密算法来进行加密后存放，session存放于服务器的内存中，所以安全性好；
3）session会在一定时间内保存在服务器上，当访问增多，会比较占用服务器性能，考虑到减轻服务器性能方面，应当使用cookie；
4）单个cookie保存的数据不能超过4k，很多浏览器都限制在一个站点最多保存20个cookie，所以建议：将登录信息等重要信息存放为session，其他信息如果需要保留，可以放在cookie中；
5）cookie的生命周期是累计的，从创建时就开始计时，20分钟后，cookie生命周期结束；session的生命周期是间隔的，从创建时，开始计时如在20分钟，没有访问session，那么session生命周期被销毁，但是如果在20分钟内（如在第19分钟时）访问过session，那么将重新计算session的生命周期，关机会造成session生命周期的结束，但是对cookie没有影响；
6）访问范围：cookie为多个用户浏览器共享，session为一个用户浏览器独享；
4.4. 为什么说session比cookie更安全
真正的cookie存在于客户端硬盘上的一个文本文件，如果cookie和session一样的话，只要cookie就好了，让客户端来分担服务器的负担，并且对于用户来说又是透明的，但实际上并不是；session的sessionID是放在cookie里的，要想攻破session的话，得分为两步：
1）首先要得到session_id，攻破cookie后，得到session_id，session_id是要有人登录，或者启动session_start才会有，无法确定什么时候会有人登录；
2）第二步是取有效的session_id，session_id是加密的，第二次session_start的时候，前一次的session_id就没有用了，session过期时session_id也会失效，想在短时间内攻破加密的session_id很难，session是针对某一次的通信而言，会话结束session也就随着消失了；
使session失效的方法：
1）关闭tomcat；
2）重启web应用；
3）session时间到；
4）无效的session；
5. token
5.1. token为什么出现
首先session的存储是需要空间的，其次，session的传递一般都是通过cookie来传递的，或者URL重写的方式，而token在服务器是可以不需要存储用户的信息的，而token的传递方式也不限于cookie传递，当然token也是可以保存起来的；
5.2. token的生成方式
浏览器第一次访问服务器，根据传过来的唯一标识userID，服务端会通过一些算法，如常用的HMAC-SHA256算法，然后加一个密钥，生成一个token，然后通过BASE64编码一下之后将这个token发送给客户端，客户端将token保存起来，下次请求时，带着token，服务器收到请求时，然后会用相同的算法和密钥去验证token，如果通过，执行业务操作，不通过则返回不通过信息。
5.3. token(令牌)和session(会话)的区别
1）token和session存在都是为了身份验证，服务器会保存一份session，可能保存到缓存，文件或数据库中；session和token都需要去管理过期时间；token和session的问题是一种时间与空间的博弈，session是空间换时间，而token是时间换空间，两者的选择要看具体情况而定；
2）token和session都是“客户端记录，每次访问携带”，但token很容易设计为自包含的，即后端不需要记录，每次发送一个无状态请求，每次解密验证，每次当场得出合法/非法结论，这一切判断依据，除了固化在CS两端的一些逻辑之外，整个信息是自包含的，是真正的无状态；而session_id一般都是一段随机字符串，需要到后端去检索session_id的有效性，而服务器重启可能会导致内存里的session没了；
3）案例比较：
session：我发给你一张身份证，但只是一张写着身体证号码的纸片，你每次来办事，我去后台查一下你的id是不是有效；
token：我发给你一张加密的身份证，以后你只要出示这张卡片，我就知道你一定是自己人；
4）安全性：作为身份认证token安全性比session好，因为每个请求都有签名还能防止监听以及重放攻击，而session就必须靠链路层来保障通讯安全，如果需要实现有状态的会话，仍然可以增加session来在服务器端保存一些状态；
5）App通常用restful API跟服务器打交道，rest是无状态的，即App不需要像浏览器那样用cookie来保存session，因此用session或者token来标识自己就够了，session由API服务器的逻辑处理，如果后端不是无状态的rest API，那么可能需要在App里保存session，可以在App里嵌入webkit，用一个隐藏的浏览器来管理cookie和session;
6）session是一种HTTP存储机制，目的是为无状态的HTTP提供持久机制，所谓session认证只是简单的把user信息存储到session里，因为session_id的不可预测性，暂且认为是安全的，这是一种认证手段；而token如果指的是OAuth Token或类似机制的话，提供的是认证和授权，认证是针对用户，授权是针对App，其目的是让某App有权访问某用户的信息，这里的token是唯一的，不可以转移到其它App上，也不可以转到其他用户上；而session只提供一种简单的认证，即有此session_id，即认为有此user的全部权利，是需要严格保密的，这个数据应该只保存在站方，不应该共享给其它网站或第三方App。简单来说，如果用户数据可能需要和第三方共享，或都允许第三方调用API接口，用token；如果永远只是自己的网站或App，用什么都无所谓；
7）token就是令牌，比如授权登录一个程序时，token就是依据，判断用户是否已经授权该软件；cookie是写在客户端的一个txt文件，里面包括登录信息之类的，这样下次登录某个网站，就会自动调用cookie自动登录用户名，session和cookie差不多，只是session是写在服务器端的文件，只需要在客户端写入cookie文件，session的状态是存储在服务器端，客户端只有session_id，而token的状态是存储在客户端的；
8）对于session，每个浏览器只需要保存自己的session_id，而服务器需要保存所有用户的session_id，如果访问服务器的用户多了， 对于服务器来说是一个巨大的开销 ， 严重限制了服务器的扩展能力。比如说服务器用两个机器组成了一个集群， 小F通过机器A登录了系统， 那session_id会保存在机器A上， 假设小F的下一次请求被转发到机器B，但机器B并没有小F的 session_id，有时候服务器会采用一点小伎俩即session sticky ，就是让小F的请求一直粘连在机器A上，但是如果机器A挂掉了，还是需要转到机器B去，那么只好做session的复制了，把session_id 在两个机器之间搬来搬去， 非常费劲。
token：如果不保存这些session_id, 就无法验证客户端发来的session_id是否合法；比如说， 小F已经登录了系统，发给他一个令牌(token)， 里边包含了小F的 user id， 下一次小F 再次通过Http 请求访问的时候， 把这个token 通过Http header 带过来就可以了，不过这和session_id没有本质区别，任何人都可以可以伪造， 想让别人无法伪造，那就需要对数据做一个签名， 比如HMAC-SHA256 算法，加上一个只有服务器自己才知道的密钥对数据做一个签名，把这个签名和数据一起作为token，由于密钥别人不知道，就无法伪造token了；
这个token服务器端不保存， 当小F把这个token发过来的时候，服务器再用同样的 HMAC-SHA256 算法和同样的密钥，对数据再计算一次签名，和token中的签名做比较，如果相同则知道小F已经登录过了，并且可以直接取到小F的user id，如果不相同，数据部分肯定被人篡改过即为非法认证；
token中的数据是明文保存的（虽然会做下编码，但那不是加密），还是可以被别人看到的，所以不能在其中保存像密码这样的敏感信息，但如果一个人的token 被别人偷走了，也会认为小偷就是合法用户，这其实和session_id被别人偷走是一样的，这样一来就不保存session_id了，只是生成token，然后验证token，用CPU计算时间获取了session存储空间。
6. webStorage
6.1. LocalStorage
持久化的存储方式，如果不手动清除，数据就永远不会过期，采用key-value的方式存储数据，底层数据接口是sqlite，按域名将数据分别保存到对应数据库文件里，它能保存更大的数据(5M)，同时保存的数据不会再发送给服务器，避免带宽浪费；
6.2. sessionStorage
和服务器端使用的session类似，是一种会话级别的缓存，关闭浏览器数据会被清除，不过有点特别的是它的作用域是窗口级别的，也就是说不同窗口间的sessionStorage数据不能共享；
6.3. sessionStorage和LocalStorage的区别
sessionStorage用于本地存储一个会话(session)中的数据，这时数据只有在同一个会话中的页面才能访问并且当会话结束后数据也随之销毁，因此sessionStorage不是一种持久化的本地存储，仅仅是会话级别的存储，当用户关闭浏览器窗口时，数据立马会被删除；localStorage用于持久化的本地存储，除非主动删除数据，否则数据是永远不会过期的。
6.4. cookie和webStorage的区别
6.4.1. cookie的特点
cookie是指某些网站为了辨别用户身份而存储在用户本地终端上的数据；
1）内存cookie：由浏览器维护，保存在内存中，浏览器关闭就消失，存在时间短；
2）硬盘cookie：保存在硬盘中，除非用户手工清朝或到了过期时间，一般不会删除；
3）用途：服务器可以设置或读取cookie中包含的信息，借此维护用户跟服务器会话中的状态，因为HTTP协议是无状态的，就是说服务器不知道用户上一次做了什么，为实现交互，就用cookie来记录；
比如，网上购物，用户选购了一个商品，服务器在向用户发送网页时还发送一段记录商品信息的cookie，当用户访问另一个页面，浏览器会把cookie发送给服务器端，于是服务器就知道用户选购了什么；
登录网站勾选“下次自动登录”，那么下次访问就不用再输入密码等信息，这是因为在第一次登录时，如果勾选了自动登录，那么服务器发送包含登录凭据（用户加密码的某种加密形式）的cookie到用户的硬盘上，第二次登录时，浏览器就会发送该cookie，服务器验证凭据，就不用再次输入密码等；
5）Web Storage是为了更大容量存储设计的，Cookie的大小是受限的，并且每次请求一个新的页面的时候Cookie都会被发送过去，这样无形中浪费了带宽，另外cookie还需要指定作用域，不可以跨域调用；cookie数据始终在同源的http请求中携带（即使不需要），即cookie在浏览器和服务器间来回传递，而sessionStorage和localStorage不会自动把数据发给服务器，仅在本地保存，cookie数据还有路径（path）的概念，可以限制cookie只属于某个路径下；
6.4.2. webStorage的特点
webStorage拥有setItem、getItem、removeItem、clear等方法，不像cookie需要前端开发者自己封装setCookie，getCookie；
sessionStorage与页面 js 数据对象的区别：页面中一般的 js 对象或数据的生存期是仅在当前页面有效，因此刷新页面或转到另一页面这样的重新加载页面的情况，数据就不存在了，而sessionStorage 只要同源的同窗口（或tab）中，刷新页面或进入同源的不同页面，数据始终存在。也就是说只要这个浏览器窗口没有关闭，加载新页面或重新加载，数据仍然存在；
webStorage 有两种机制：
1）sessionStorage 为每一个给定的源维持一个独立的存储区域，该存储区域在页面会话期间可用（浏览器是打开状态，包括页面重载和恢复）；localStorage 同上，但浏览器关闭之后，重新打开数据还是存在；
2）webStorage 支持事件通知机制，可以将数据更新的通知发送给监听者，WebStorage 的 api 接口使用更方便；
6.4.3. webStorage和cookie的区别
6.4.3.1. 生命周期
cookie：可设置失效时间，没有设置的话，默认是关闭浏览器后失效；
localStorage：除非被手动清除，否则将会永久保存；
sessionStorage： 仅在当前网页会话下有效，关闭页面或浏览器后就会被清除；
6.4.3.2. 存放数据大小
cookie：4KB左右；
localStorage和sessionStorage：可以保存5MB的信息；
6.4.3.3. http请求
cookie：每次都会携带在HTTP头中，如果使用cookie保存过多数据会带来性能问题；
localStorage和sessionStorage：仅在客户端（即浏览器）中保存，不参与和服务器的通信；
6.4.3.4. 易用性
cookie：需要程序员自己封装，源生的Cookie接口不友好；
localStorage和sessionStorage：源生接口可以接受，亦可再次封装来对Object和Array有更好的支持；
6.4.3.5. 应用场景：
从安全性来说，因为每次http请求都会携带cookie信息，这样无形中浪费了带宽，所以cookie应该尽可能少的使用，另外cookie还需要指定作用域，不可以跨域调用，限制比较多。但是用来识别用户登录来说，cookie还是比webStorage更好用，其他情况下，可以使用webStorage，就用webStorage;
webStorage在存储数据的大小上面秒杀了cookie;
localStorage和sessionStorage唯一的差别一个是永久保存在浏览器里面，一个是关闭网页就清除了信息，localStorage可以用来跨页面传递参数，sessionStorage用来保存一些临时的数据，防止用户刷新页面之后丢失了一些参数;
6.4.3.6. 浏览器支持情况
localStorage和sessionStorage是html5才应用的新特性，可能有些浏览器并不支持。
6.4.3.7. 数据存放处
<!doctype html>
<html lang="en">
<head>
<meta charset="UTF-8">
<meta name="viewport"
content="width=device-width, user-scalable=no, initial-scale=1.0, maximum-scale=1.0, minimum-scale=1.0">
<meta http-equiv="X-UA-Compatible" content="ie=edge">
<title>本地存储</title>
</head>
<body>
<div>打开控制台查看console</div>
<p><a target="_blank" href="https://github.com/OBKoro1/article-demo/blob/master/2017/cookieStorage/index.html">查看代码文件</a></p>
<script>
cookieFn();
strogeFn();
function cookieFn() {
var dataCookie='110';
document.cookie = 'token' + "=" +dataCookie;//直接设置cookie
function getCookie(name) { //获取指定名称的cookie值
// (^| )name=([^;]*)(;|$),match[0]为与整个正则表达式匹配的字符串，match[i]为正则表达式捕获数组相匹配的数组；
var arr = document.cookie.match(new RegExp("(^| )"+name+"=([^;]*)(;|$)"));
if(arr != null) {
console.log(arr,'正则表达式捕获数组相匹配的数组');
return unescape(arr[2]);
}
return null;
}
var cookieData=getCookie('token');
console.log(cookieData,'获取指定名称的cookie值');
function setTime() {
//存储cookie值并且设置cookie过期时间
var date=new Date();
var expiresDays=10;//设置十天过期
date.setTime(date.getTime()+expiresDays*24*3600*1000);
document.cookie="userId=828; expires="+date.toGMTString();
console.log(document.cookie,'存储cookie值并且设置cookie过期时间');
}
setTime();
function delCookie(cookieName1) {
//删除cookie
var date2=new Date();
date2.setTime(date2.getTime()-10001);//把时间设置为过去的时间，会自动删除
document.cookie= cookieName1+"=v; expires="+date2.toGMTString();
console.log(document.cookie,'删除cookie');
}
delCookie('userId');
}
function strogeFn() {
var name='sessionData';
var num=120;
sessionStorage.setItem(name,num);//存储数据
sessionStorage.setItem('value2',119);
let dataAll=sessionStorage.valueOf();//获取全部数据
console.log(dataAll,'获取全部数据');
var dataSession=sessionStorage.getItem(name);//获取指定键名数据
var dataSession2=sessionStorage.sessionData;//sessionStorage是js对象，也可以使用key的方式来获取值
console.log(dataSession,dataSession2,'获取指定键名数据');
sessionStorage.removeItem(name); //删除指定键名数据
console.log(dataAll,'获取全部数据1');
sessionStorage.clear();//清空缓存数据：localStorage.clear();
console.log(dataAll,'获取全部数据2');
}
</script>
</body>
</html>
6.4.4. webStorage和cookie的操作异同
6.4.4.1. cookie的操作
// 保存cookie
var dataCookie='110';
document.cookie = 'token' + "=" +dataCookie;
// 获取指定名称的cookie
function getCookie(name) { //获取指定名称的cookie值
// (^| )name=([^;]*)(;|$),match[0]为与整个正则表达式匹配的字符串，match[i]为正则表达式捕获数组相匹配的数组；
var arr = document.cookie.match(new RegExp("(^| )"+name+"=([^;]*)(;|$)"));
if(arr != null) {
console.log(arr);
return unescape(arr[2]);
}
return null;
}
var cookieData=getCookie('token'); //cookie赋值给变量。
6.4.4.2. webStorage的操作
var name='sessionData';
var num=120;
sessionStorage.setItem(name,num);//存储数据
sessionStorage.setItem('value2',119);
let dataAll=sessionStorage.valueOf();//获取全部数据
console.log(dataAll,'获取全部数据');
var dataSession=sessionStorage.getItem(name);//获取指定键名数据
var dataSession2=sessionStorage.sessionData;//sessionStorage是js对象，也可以使用key的方式来获取值
console.log(dataSession,dataSession2,'获取指定键名数据');
sessionStorage.removeItem(name); //删除指定键名数据
console.log(dataAll,'获取全部数据1');
sessionStorage.clear();//清空缓存数据：localStorage.clear();
console.log(dataAll,'获取全部数据2');
