什么是Web Storage？
web storage是HTML5规范中提出的一种本地存储解决方案。在这之前，我们在开发中遇到本地存储问题时，通常有两种解决方式
-
cookie：兼容性最好，但也有不少问题，下面会简单做下对比
-
各浏览器实现的非标准化的本地存储方案，如IE的userData，firefox的global storage等，毫无疑问，最大的问题是兼容性
session storage、local storage的区别
session storage的作用在于：将数据存储在本地，只有当次会话中同域的页面才能访问，这意味着：
-
会话一旦结束，之前存储的数据就销毁，不可以访问（比如关闭标签或窗口）
-
页面存储的数据，只有同域的页面能够访问；比如同域的两个页面demo-1.html、demo-2.html，当前打开了demo1.html， 并存储了一段数据A（细节略）；接着在当前窗口，切换到demo-2.html，demo2.html里的脚本可访问A；如果此时切换到的不是demo- 2.html，而是其他域的页面，则无法访问A
local storage则比session storage少了一些限制，一个页面里设置的数据，只要同个域下的页面均可以访问。如果不手动删除数据，理论上这些存储的数据是会一直存在的
相对cookie有哪些优势
关于web storage相对于cookie的优势，网上有不少分析了，这里简单列出关键的几点：
-
存储空间更大：cookie的大小限制从数K到数M不等，虽然HTML5规范里没有明确说明浏览器需提供多大的本地存储空间，但一般支持的浏览器都会提供数M以上的存储空间
-
数据仅存储在本地，在与服务器发送交互的时候不会传送到服务器：当向服务器发起请求时，之前设置的cookie会随着请求一起发送到服务器，这对带 宽来说是一种浪费，尤其同个域下有多个业务时这种带宽浪费的问题尤为明显（曾见过某业务在cokkie里设置了将近1M的数据，god～）
-
更加友好的接口，操作数据更加方便：原生API操作cookie很麻烦很麻烦～
-
独立的存储空间：每个域（包括子域）有独立的存储空间，各个存储空间是完全独立的。体验过同域下cookie相互覆盖导致的问题的童鞋应该深有体会
API简单介绍
1个属性：length；5个方法：setItem、getItem、removeItem、clear
length：
- 当前Storage对象中存储的key/value对的总数
setItem(key, value)
-
将key对象的值设置为value，value为String类型
-
当设置失败，比如用户将本地存储禁用，或者本地存储超过限制的大小时，抛出QuotaExceededError错误
getItem(key)
- 返回key对应的值，如不存在，返回null
removeItem(key)
-
如果key在storage中存在，将key对应的key/value对从storage对象中删除；注意：不会返回删除的 value
-
如果key在storage中不存在，不进行任何处理
clear()
- 清除Storage对象上所有的key-value值
key(index)
-
返回index对应位置的key值，当index>length时，返回null
-
往storage对象上添加key-value值，通过key(index)取回的键是不固定的，跟通过for...in遍历普通的对象一样，依赖于浏览器的实现
storage事件
根据标准的说明，当本地存储的数据发生变化时候，会触发storage事件，对应的事件对象包含了以下属性：
- key：被更新或删除的键
- oldValue：键更新前对应的value，如果键原先不存在，则oldValue为null
- newValue：键更新后的value，如果键被删除，则newValue为null
- url：storage事件发生的源（页面url）
- storageArae：一个引用，指向当前发生变化的localStorage或sessionStorage
在storage事件的实现上，各浏览器出现了前端工程师喜闻乐见的兼容性问题，主要体现在两个方面：
- 触发事件的对象
- 事件触发时，对应事件对象支持的属性（TODO）
兼容性问题
1、触发的条件
The storage event is fired when a storage area changes, as described in the previous two sections (for session storage, for local storage).
When this happens, the user agent must queue a task to fire an event with the name storage, which does not bubble and is not cancelable, and which uses the StorageEvent interface, at each Window object whose Document object has a Storage object that is affected.
简单概括：当本地存储的数据被修改的时候，会触发storage事件，并将事件放进任务队列里去
- storage不会冒泡，也不可取消
- 在所有本地存储被影响到的window对象上触发
上面引用的那段文字似乎没什么特别之处。按照上面的描述假设我当前打开了两个标签，分别访问的是同个域下的页面，如www.example.com下的demo-1.html，demo-2.html
在demo-1.html上有如下代码
window.onstorage = function(){
console.log('storage changed in demo-1');
};
setTimeout(function(){
window.localStorage.intro = 'my name is casper';
}, 3000);
在demo-2.html上有如下代码
window.onstorage = function(){
console.log('storage changed in demo-2');
};
3秒后会发生神马事情？按照预计，demo-1.html、demo-2.html页面的storage都被触发，并打印相关日志，但实际上，只有demo-2.html页面有日志打印出来
“storage changed in demo-2”
在最初的时候有些困惑，于是向群里的兄弟请教，Hax帮忙给了回答，如下
2、事件触发的对象
When the setItem(), removeItem(), and clear() methods are called on a Storage object x that is associated with a local storage area, if the methods did something, then in every Document object whose Window object's localStorage attribute's Storage object is associated with the same storage area, other than x, a storage event must be fired, as described below.
简单概括：假如Storage对象X被修改，如添加、删除ke/value等，则在所有受到影响的文档的window对象上触发storage事件，除了X所在的那个文档 于是之前的现象就解释得通了，如果光看storage event的描述，很容易就掉坑里，很明显的前后不一致。据说在之前的版本里面这里的规定更加不明确，不想考古了，知道现在标准是怎么规定的就行了。
3、事件触发时，对应事件对象支持的属性（TODO）
需要较多的测试工作，小本子测试不方便，未免误导大家，先留个TODO了
可以看下百度的兄弟的总结，相当不错，推荐下（ps：里面的结论未实际测试过）：
http://www.baiduux.com/blog/2010/06/21/web-storage%E5%85%A8%E8%A7%A3%E6%9E%90/
写在后面
- 本文相关的话题，比如cookie在不同浏览器的容量限制、可能存在的问题，web storage的安全相关的内容等，暂不展开，因为内容也不少
- 文章内容如有错漏，烦请指出 :)
