做心愿墙二期的时候，有这么一个需求：
用户许愿的时候要在pageA填写信息，填写过程中可以跳到pageB选择一个歌曲，然后自动跳回pageA，当然跳回pageA的时候势必要把pageB中选择的信息带到pageA。老大觉得最好把填写信息这件事放在同一个页面，然而这就涉及到交互的改变，产品和UI都需要作出调整，毕竟是单页设计，况且选歌这件事是个大的动作，最后我决定还是简单点就用cookie了。
cookie
Why cookie exists?
http协议是没有无状态的，这就意味着client向server请求的时候，server并不知道client是谁，或是client的登录状态，所以93年在我表妹出生的时候，网景一个叫LM的哥们发明了这个东西。
Where does cookie come from？
cookie是由HTTP服务器生成的，client向server请求之后，server把信息和它生成的cookie一起返给client（在http头部加入Set-cookie字段），cookie就被保存在了浏览器中，下次client再请求server的时候就会带着cookie一起（依然是那个Set-cookie字段），再之后C和S就可以愉快玩耍了。
What is cookie？
cookie的组成是一些键值对，每个key可以为它单独设置过期时间（Expires），过期会被浏览器删除，默认是关闭窗口的时间。cookie这个东西很适合存一些小的数据，毕竟只有4KB。很蛋疼的是，控制台里打出document.cookie就会发现，这些对对儿竟然都被连起来变成了一坨字符串，所以眼睁睁看到key就在那里，然而value却不能一下子拿出来，就酱紫："key1=value1;key2=value2;..."。所以操作cookie的时候要自己封装setCookie(key,value)、getCookie(key)、还有clearCookie()等常用的操作（也就是一堆对字符串的）。
正因为一个document.cookie就能查看，所以对于这种明文传输来说，隐秘信息是一定不能用到cookie里的，而且cookie这个东西很容易就能被篡改。拿登录状态来说，server端解析http，收到Cookie里面的authed=true，则认为此者可信。然而不能就这么轻易相信啊，手动把authed改为true很轻易就骗过去了好嘛。
localStorage和sessionStorage
相同点：
都是本地存储
不会被发到服务器去，一般大小在5M到10M之间。
内置接口使用情况相同
- set操作：localStorage/sessionStorage.setItem("key","value");
由于value值是以字符串形式存储，因此存object的时候要用JSON.stringify(obj)。 - get操作：localStorage/sessionStorage.getItem("key");
如获取object形式的value值，就将value值JSON.parse()一下。
JSON.parse(localStorage.getItem("localInfo")) - remove操作：localStorage/sessionStorage.removeItem("key");
- 清空操作：localStorage/sessionStorage.clear();
不同点：
直接随便打开一个网页，控制台操作：
一开始会发现这个页面当中localStorage没有信息，而sessionStorage里面有一条。向两者分别添加一条数据之后：
localStorage和sessionStorage各增加了一条信息。
刷新页面，清空Console，会发现localStorage和sessionStorage内的信息并没有改变：
什么时候会消失呢？在浏览器未关闭，而当前页面被关闭之后，重新输入这个页面的地址，在console里面查看localStorage和sessionStorage。
会发现：localStorage依然保存有之前的信息，而sessionStorage则清空了，也就是说，sessionStorage里信息的生存时间仅限于当前这个页面被关闭之前。至于localStorage内的信息生存时间，则是永久的，除非手动强制删除。
此外，两者的作用域不同，意思是localStorage在同一个域名下的页面窗口中是共享的，但不同源的页面是不会看到相同信息的。sessionStorage就好理解了，窗口不同则内容比不同。
In all
| localStorage | sessionStorage | |
|---|---|---|
| deadline | 永久 | 当前页关闭 |
| 作用域 | 同源窗口共享 | 窗口间不共享 |
