漫谈 Web Storage API 既本地存储的 8 个 Features 和 20 个 BUG
Storage 是种简略又简单的本地数据存储办法，简略在于它使用方便，简单在于它有有数的 BUG，为了可能安心的应用它，XJ 花了很多工夫，写了一个开源的 xj.storage 插件，但在这篇文章中，插件并不是重点，XJ 在编写插件的过程中，通过查阅材料和实际，积攒了大量对于 Storage 的笔记，本着记录和开源的想法，于是将那些笔记整顿成了这篇文章，心愿能帮到其余须要用到 Storage 的开发者。
Storage 有两个实例对象既 localStorage 和 sessionStorage，这两个实例对象的属性和办法都是雷同的，只是应用的场景和一些细节体现有所区别，XJ 就不在这里科普这两个实例对象的根底内容了，这些常识大伙随便搜寻都能找到一堆相干的文章，在这里咱们着重探讨 Storage 存在的一些难以弄清的个性细节，以及一些 BUG 和解决方案，即便你非常相熟 Storage，也应该会有些意外发现的。
01. Storage 的 8 个 Features
Storage 存储的一些体现细节，常常会让人感觉到隐隐约约，诸如最大 5MB 的配额，到底是 localStorage 和 sessionStorage 平分的？还是共用的？还是说各自有享有？配额在面对子域名不同的跨域时是如何失效的？这类问题你往往很难有一个全面的意识，这是因为规范在不同浏览器的最终体现会存在差别，所以科普向文章就算有提到也不肯定齐全精确，接下来咱们就来讲讲这些隐隐约约的细节。
————
01.01. 同个窗口下的 sessionStorage 数据才会被共享
localStorage 依照规范只有 protocol(协定) 和 hostname(主机名) 和 port(端口)都雷同 (同源)，就能读写同一份 localStorage 数据，而 sessionStorage 的要求比 localStorage 严苛，除了协定主机名端口要求雷同不能跨域之外，它还要求在同个窗口(或者说同个 Tab 标签页) 才行，如果是两个窗口(或者说两个 Tab 标签页)，那么即便 URL 雷同，也是读取不到数据的，并且在操作数据时，Storage 事件也不会响应，惟一的一种例外，就是在页面中的 iframe，如果 iframe 的 src 地址和页面是同源的，那么页面和 iframe 所在的页面，数据就能够被共享，并且在操作数据的时候，Storage 事件也会在页面和 iframe 所在的页面之间被响应。
————
01.02. Storage 的规范存储配额到底是如何进行划分的
同源的 localStorage 和 sessionStorage 依据规范各自享有 5MB 的配额，加起来就是 10MB，但并非所有浏览器的配额都是 5MB，在晚期规范尚未明确的时候，有些浏览器是应用了 2.5MB 或 10MB 的配额，而在之后即便是规范曾经明确了，还是有局部浏览器的配额并不是 5MB，例如说 Android4.3 和 Android7.0，这两个版本的 Android Browser 配额就只有 2.5MB，这实际上是一个 BUG，你能够到这个 https://stackoverflow.com/questions/2989284 页面理解更多的配额细节，如果想理解你的浏览器到底能存多少内容，能够到这个 https://arty.name/localstorage.html 页面或者这个 http://dev-test.nemikor.com/web-storage/support-test/ 页面在线测试。
————
01.03. Storage 键值对存储的一些字符串数值计算细节
首先是存储空间不辨别单双字节，也就是说单字节的数字字母和双字节的中文符号，都是被算做 1，但 Unicode 编码大于 65535 的四字节字符会被算作是 2，其次是键值对的 key 和 value 都会占据空间，并非只有 value 才会被计算，最初是 setItem(key, null) 这种写法，null 会被转遍为字符串，所以它会占用 4 个字符，而不是 0 个字符，所以实际上最初可用的存储空间会比你设想中更少。
————
01.04. 对于 sessionStorage 5MB 存储配额的其余细节
在下面的第一节中，咱们有提到 sessionStorage 的数据在不同窗口 (或者说不同 Tab 标签页) 之间不能共享，在下面第二节中，咱们有提到 sessionStorage 依据规范享有 5MB 的配额，所以实际上 sessionStorage 是在每个页面 (或者说每个 Tab 标签页) 享有 5MB 的配额，但如果页面中有同源的 iframe 标签页面，则 5MB 的配额会和这些 iframe 标签页面共享，然而独自关上这些 iframe 标签的 src 属性所指向的地址，这些页面不会呈现之前设置的数据，因为不是同个窗口或 Tab 标签页，它们又独自享有 5MB 配额。
————
01.05. key() 办法无奈确保键值对被获取时的先后顺序
localStorage.key() 办法和 sessionStorage.key() 办法，都是传入索引数值就能够失去对应地位上的数据（当然前提是索引的指标上的确有数据），但索引的数值大小和你存入数据的先后顺序并没有什么必然的关系，例如说按程序存入了 a, b, c 三个数据，然而应用 key(1), key(2), key(3) 获取数据时，不肯定能顺次失去 a, b, c 三个数据，这是因为存入 Storage 对象内的数据，它们排列程序由浏览器厂商本人决定，不肯定是依照存入的程序进行排序的，当减少或者删除数据时，索引对应的值也可能有变动，Chrome 浏览器可能会自行把 key 值排序后再去输入，而 IE 和 Firefox 则不会依照程序，它们既不会主动排序，也不会依照写入时的程序。
————
01.06. 尽量应用规范办法来进行操作并留神数据的键名
假如执行了 localStorage.setItem('constructor', 'test') 这样的操作，会产生什么事？咱们能胜利的存入这个数据吗？答案是能够的，但存入后只能用 localStorage.getItem('constructor') 这样的写法来获取 'test' 的后果，那么在存入数据后对象自身的 constructor 属性会受到影响吗？答案是并不会，localStorage.constructor 仍然会返回 Storage 构造函数，在大多数基础教程中都提到，除了用 setItem() 和 getItem() 之外，也可用中括号如 localStorage[key] 或点运算符如 localStorage.key 来对数据进行存取操作，但同时那些教程也会揭示你最好不要这样做，因为这是不标准的，而更深层次的起因，首先是前面第二章的 BUG 中咱们将会提到的，中括号的写法和点运算符的写法在 IE 中可能会引发 BUG，其次是如果应用中括号的写法或点运算符的写法来存取数据，如果数据的名称和 localStorage 对象或 sessionStorage 对象原有的属性或者办法反复了，就可能导致一些可怕的结果，例如说会把对象继承来的属性或办法笼罩，或者是获取的时候返回谬误的后果值，所以尽量应用规范办法来操作并留神数据的键名不要反复。
————
01.07. 5MB 的存储配额也是有可能会把咱们的硬盘挤爆
相干文章：https://feross.org/fill-disk/… 这个网站试试看，浏览器之所以没有依据规范限度总的存储配额，是因为诸如 GitHub 或 wordPress 等网站，它们容许用户应用二级域名创立本人的站点，在这种状况下 Storage 空间被限度，就有可能导致主站点和子站点的存储量不够用，然而说到底，这个问题对于网站开发者和用户而言都是无解的，因为规范如何履行是浏览器厂商的问题，网站开发者根本无法管制，只能盲目的不要滥用，而站点的存储空间是否会被滥用则取决于网站开发者的盲目，用户也没法管制，所以这个景象，咱们理解一下也就罢了，毕竟空间总量，限度有限度的毛病，不限度有不限度的益处，这个问题其实并没有特地完满的解决方案。
————
01.08. 借助 JSON 数据格式来保留数据时存在的局限性
基本上跟 Storage 存储相干的插件，无一例外都是用 JSON.stringify() 办法转存数据，之后获取数据时再用 JSON.parse() 办法对数据进行解析，以此来让 Storage 可能反对其余类型的数据，而不是局限于字符串，但应用 JSON 作为数据的直达格局也是有局限的，JSON 作为一种通用的数据存储格局，它还须要思考到其它语言是否可解析，所以它不会去反对一些在其余语言上无奈被辨认的类型值，这也是为什么咱们无奈在 JSON 中存储 undefined 和 Symbol 等类型值，也无奈保留 NaN 和 Infinity 等非凡值的起因。
02. Storage 的 20 个 BUG
上面提到的 BUG，后面九个是 canIuse 上有记录的，前面那些 BUG 则是 XJ 在查找材料以及实际的时候发现的，尽管有些 BUG 只存在于一些常见的场景或老旧的浏览器，在以后的环境下可能曾经没什么意义了，即便不晓得且不解决也无所谓，但 XJ 还是决定尽可能的将它们列举进去，兴许还会有人须要用到呢？但集体的见识总是无限的，也欢送各位同行踊跃反馈，争取就算解决不了，也起码有个记录。
————
02.01. 在 IE11 中可能会无奈同步 localStorage 的值
问题形容：https://stackoverflow.com/que…，IE11 在不同的 Tab 标签页面之间无奈正确同步 localStorage 的值。
解决方案：这个问题实际上是 IE 的 localStorage 对象无奈及时自动更新导致的，在 A 页面批改数据，在 B 页面无奈读取到这个被批改过的数据，B 页面会持续失去批改前的旧值，解决这个问题的办法有两种，第一种是在 B 页面获取数据时先用 setItem() 存入一个随机数，以此强制 localStorage 对象更新，更新后再获取数据就不会出错了，第二种则是绑定 Storage 事件，在这个事件中监听指标数据的变动，应用 event 对象的 newValue 属性来获取最新的后果值，event.newValue 属性的返回值总是能够被置信的。
————
02.02. Windows 8 的 IE10 会因为完整性设置导致出错
问题形容：https://stackoverflow.com/que…，在 Windows 8 的 IE10 中，如果相干的用户配置文件中，文件夹的 ” 完整性 ” 设置有问题（可能是是零碎清理器导致的），那 localStorage 就可能会操作失败，谬误音讯是 SCRIPT5: Access is denied。
解决方案：问题形容的页面有具体的解决办法，但因为是须要用户在本人的零碎中进行修复操作，所以实际上并没有什么意义，因为普通用户哪里会去解决这种问题，对于前端开发者而言，这是零碎级别的问题，在浏览器的层面上根本无法解决，所以说即便你的代码没有问题，也不见得就不会报错，所以最稳当的做法，就是做好容错解决，将所有操作都放到 try…catch 中执行，防止出错后代码被卡住。
————
02.03. 在 Safari 中存储大量数据会导致浏览器被卡住
问题形容：https://bugs.webkit.org/show_…，MacOS 和 IOS 的 Safari，间断存储大量数据时会被卡住，无奈响应。
解决方案：这个问题仿佛在 2016 年时曾经被修复了，XJ 在 Safari(MacOS12.1) 和 Safari(IOS12.2) 中测试都没法复现这 BUG，所以 XJ 也没有什么计划能解决它，只能是尽量避免这种间断操作大额数据的状况，实际上操作大额数据在 IE11 中有 BUG，前面会再提到。
————
02.04. window 的 Storage 事件在 IE 中是齐全谬误的
问题形容：首先是 IE 的 Storage 事件会在以后页面也触发，依照规范，事件不该在操作数据的页面被触发，这可能导致多个窗口问题，iframe 也可能会受到影响，其次是 IE11 中 Storage 事件的 newValue 会等于 oldValue，依照规范应该返回新值才对。
解决方案：第一个问题可通过标记符来解决，为每个页面创立标记符，保留数据时将标记符和后果值组成对象，用 JSON.stringify() 转成 JSON 格局字符串再保留，之后获取数据时再用 JSON.parse() 解析数据，判断到数据中的标记符等于以后页面的标记符，就示意事件是当前页操作引发的，就不要响应 Storage 事件，实际上你还得革新 removeItem() 和 clear()，因为这两个办法无奈携带数据，标记符也就无奈传递，所以在执行这两个办法之前，得先执行 setItem() 模仿 removeItem() 和 clear()，更多细节可参考 StackOverflow 和 xj.storage 插件，第二个问题既 IE11 的 newValue 和 oldValue 相等的 BUG，XJ 在 Windows10 的 IE11 中实测后没能复现，兴许是前期的 IE11 进行补丁更新曾经修复了这个问题，XJ 临时没什么解决的计划，期待其余其余开发者的补充。
————
02.05. IE 无奈保留一些 Ascii 编码 < 32 的控制字符
问题形容：IE 不反对存储编码低于 x20 既 < 32 的 ASCII 字符，这些都是控制字符，遭逢时会报 SCRIPT87: 参数有效 谬误。
解决方案：在保留数据前先检测浏览器，如果是 IE，那就应用 replace(/[\u0001-\u001F]/g, '') 打消管制字符串，或者是应用特定字符代替这个控制字符存入，等获取时再替换回去，实际上应用 JSON.stringify() 格式化要保留的数据，也可能解决这个字符的问题。
————
02.06. IE 无奈在 file 的协定下应用 Storage 的存储
问题形容：IE 在 file 协定下关上有 Storage 操作的 html 文件会报错，localStorage 和 sessionStorage 都为 undefined。
解决方案：将页面放到服务器，应用 http 或 https 协定读取，或是将代码复制到 JSRun 或 CodePen 等反对在线运行的环境下执行。
————
02.07. IE8/9 在协定或端口不同的状况下数据可被共享
问题形容：依照规范，当页面 URL 的协定或端口或域名不同时，Storage 数据就不能共享，但 IE8/9 忽视了协定（http 或 https）和端口的区别，只有主机名既 location.hostname 雷同，Storage 的数据就能够被共享，这就有可能产生数据被笼罩或者透露的危险。
解决方案：能够在保留数据的时候，把以后页面的协定和端口也追随数据一并保留下来，在操作数据时对协定和端口进行判断，防止数据的笼罩或透露，当然更简略的解决形式是间接忽视，因为 IE8/9 切实是太老旧了，目前曾经没什么人应用，花力量解决也没什么意义。
————
02.08. 在 IOS5/IOS6 中 Storage 数据可能会呈现失落
问题形容：在 IOS5/IOS6 中，Storage 数据被保留在一个有时会被零碎主动革除的地位，也就是说数据随时可能会因为被革除而失落。
解决方案：任何的时候都要做好数据不存在的容错解决，实际上就算没这 BUG，在应用 Storage 的时候也总是要思考操作失败的状况。
————
02.09. 浏览器在隐身状态或无痕模式下操作可能会出错
问题形容：https://stackoverflow.com/a/1…，晚期的 Safari(MacOS 和 IOS) 和 Android Browser，在隐身状态或无痕模式下并不反对 localStorage 和 sessionStorage，这种状况下可能体现为，这两个对象的办法和属性都是失常的，然而它们的存储空间被设置为 0 MB，也就是说你根本无法往这两个对象中存入任何数据，这种状况下浏览器可能会引发一个 QUOTA_EXCEEDED_ERR 的谬误。
解决方案：实际上 XJ 本人做了测试，发现 Safari(MacOS12.1) 和 Safari(IOS12.2) 和 Android Browser(Android7.1) 在隐身模式下都不会出错了，然而这也不能证实这个问题就不会在其余场景下呈现，所以任何时候都要思考 Storage 操作失败的场景，将操作都放在 try…catch 中执行是最稳当的，出错也不会导致所有 JS 逻辑被中断，更具体的操作细节，可参考 StackOverflow 页面提供的代码。
————
02.10. 不必规范办法保留数据则存储量可能会超过 5MB
问题形容：http://dev-test.nemikor.com/w…，除了规范的 setItem() 办法之外，咱们其实还能够用中括号表示法如 localStorage[key] 来设置键值对以保留数据，但不少浏览器在用中括号设置键值对时，不会强制执行 localStorage 和 sessionStorage 的 5MB 配额，也就是说即便被额度曾经超出，也能够存下而不报错，但页面刷新后值就会失落，因为超出存储下限。
解决方案：尽量用 setItem() 这些规范办法来操作，很多科普文章也会有这样的倡议，尽管往往他们本人也不晓得为什么要这样做。
————
02.11. IE9 用数字作键值和中括号表示法操作可能出错
问题形容：http://dev-test.nemikor.com/w…，如题，XJ 没有 IE9，无奈复现，如果你有的话可进入链接页实测一下。
解决方案：之前曾经说过，尽量应用规范办法存取数据，不要用中括号操作，其次就是 key 值最好别用纯数字，防止引发奇怪问题。
————
02.12. IE8 的 StorageEvent 事件对象缺失了一些属性
问题形容：IE8 的 Storage 事件的对象，并没有 Storage.key, Storage.oldValue, Storage.newValue, Storage.url 这些属性。
解决方案：将须要的 Storage 数据保留成对象，在触发 Storage 事件后，将后果值和之前保留的那对象比对，来获取缺失的这些属性。
————
02.13. IE 的 Storage 事件对象，属性无值时会返回空
问题形容：IE 的 Storage 事件对象，key, oldValue, newValue 属性在不存在时会返回 ''，按规范应返回 null 才对。
解决方案：这问题可和下面第四个问题既 04. window 的 Storage 事件在 IE 中是齐全谬误的 一起解决，在用 JSON.stringify() 保留标记符和目标值时，可减少一个操作行为的属性，用于记录这事件到底是什么行为导致的，数据结构是这样的 {id: 标记符, act: 操作行为, data: 目标值}，之后在 Storage 事件回调中应用 JSON.parse() 解析数据，判断数据操作的行为，if(act === 'clear') 则 key = oldValue = newValue = null，if(act === 'remove') 则 newValue = null，if(act === 'create') 则 oldValue = null，实际上这个革新难度还是有点大的，如果你嫌操作切实是太麻烦了，不如尝试应用 xj.storage 插件来帮你解决这个问题吧。
————
02.14. IE 的革除数据的办法会反复触发 Storage 事件
问题形容：依据规范，如果 Storage 对象中曾经没数据，那调用 clear() 办法就不该触发 Storage 事件，但 IE 不论是否还有数据，调用 clear() 办法时总是会触发事件，惟一值得庆幸的是，用 removeItem() 移除不存在的数据时，IE 不会再次触发事件。
解决方案：革新 clear() 办法，如果判断到以后的环境是 IE 浏览器，那么在执行该办法之前，先应用 localStorage.length 或 sessionStorage.length 判断 Storage 对象中是否还有数据，如果 length 属性返回 0 就是没有数据了，那间接 return 即可。
————
02.15. IE 设置了雷同后果值时也会触发 Storage 事件
问题形容：依据规范，如果为一个 key 值，设置了一个跟之前雷同的 value 值，是不该触发 Storage 事件的，因为后果没变的状况下响应事件也没有意义，但 IE 在这种操作下会触发 Storage 事件，在事件的回调中，event.oldValue === event.newValue。
解决方案：革新 setItem() 办法，在设置值之前先进行获取，如果获取的值和设置的值雷同，就不要持续了，或是在 Storage 事件回调中检测 event.oldValue 和 event.newValue 属性，如果这两个属性相等，那么就间接 return 返回，不再继续执行回调了。
————
02.16. IE9 的 sessionStorage 的存储事件触发有异样
问题形容：依照规范，sessionStorage 的操作并不会触发 Storage 事件，因为 sessionStorage 的数据并不会在同源的页面之间共享，惟一的例外是页面中的 iframe 标签，并且这个 iframe 标签的地址和以后页面是同源的，然而 IE9 还有另一种例外，如果用 window.open() 关上了同源的页面，无论关上的页面是以新 Tab 标签页关上，还是以独自新窗口的模式关上的，在 iframe 中进行 sessionStorage 的批改操作或移除操作，在新关上的 Tab 标签页，或者新关上的独自窗口页面中，也会响应 Storage 的事件。
解决方案：这问题是 XJ 在很早以前发现的，当初 XJ 曾经没有 IE9 可复现这个问题了，IE10/11 都不会呈现这种状况，过后的记录也有些含糊，所以 XJ 对这个 BUG 并不是很必定，如果 BUG 真的存在，可先拿到 window.open() 办法返回的 window 对象，为这个对象设置一个 preventStorage = [] 属性，将不想让窗口响应的 key 值写入，而后在新关上的窗口页面，在 Storage 事件的回调中，检测到数组中有以后响应事件的 event.key 值，那就不要响应，只是这解决方案 XJ 本人没有理论测试过，所以不肯定无效。
————
02.17. IE 在 Storage 事件回调中获取数据可能会出错
问题形容：在 IE 中应用 for 循环执行 10 次的 setItem()，存入的值从 0 到 9 顺次递增，并绑定 Storage 事件，那么最初的后果是，事件会被响应 10 次，但会在 10 次 setItem() 操作完结后才响应，在事件回调中用 getItem() 获取数据，总会失去 9。
解决方案：这个问题其实是由异步导致的，依照规范 Storage 的所有操作都应该是同步的，但 IE 却并不是如此，它的事件回调被设置成了异步，这就导致在事件回调中应用 getItem() 获取数据，可能会失去一个谬误的后果，如果想得到操作数据那一刻的值，可改用 Storage 事件对象的 event.newValue 属性，这个属性返回的总是操作数据后那一刻数据的最新值，因为回调尽管会被提早执行，但 storageEvent 事件对象却是在执行 setItem() 后就立刻生成的，所以对象上的属性都是那一刻的值，就不会呈现不精确的状况。
————
02.18. Safari 的 Storage 事件也会在操作数据页响应
问题形容：https://stackoverflow.com/que…，在下面的第四个问题既 04. window 的 Storage 事件在 IE 中是齐全谬误的 中有提到，IE 的 Storage 事件会在操作数据的页面也响应，实际上这问题在 2018 年 MacOS 10.14 的 Safari 中也是存在的。
解决方案：参考第四个问题的解决方案，不要用网络上流传的借助 event.url 属性或 document.hasFocus() 办法去判断，前者在多个 Tab 标签页关上了雷同地址时就没用了，后者如果其余 Tab 标签页操作了 Storage 数据，以后聚焦页会无奈响应 Storage 事件。
————
02.19. 事件对象初始化的 initStorageEvent() 有 BUG
问题形容：initStorageEvent() 办法用于初始化 Storage 事件对象，当咱们须要手动触发 Storage 事件时就须要用到它，尽管实际上该办法已不被举荐应用，但它在所有浏览器中始终是能运行的，但它在 Safari(MacOS) 和 Safari(IOS) 和 Android Browser 中存在着一个 BUG，当咱们面对 clear() 操作须要将 initStorageEvent() 办法的 key 参数设置为 null 时，该办法会主动将咱们传入的 null 转为字符串的 'null'，后果就导致 Storage 事件回调中，event.key 不等于 null 而是字符串 'null'。
解决方案：如果是 clear() 操作触发的 Storage 事件，那么 event.oldValue 和 event.newValue 都是等于 null，咱们能够依据这两个参数判断 Storage 事件是否为 clear() 操作触发的，如果是则应用 event.key 属性的时候，就得创立变量来应用既 var key = (event.key === 'null' ? null : event.key)，为什么要创立一个 key 变量应用？为什么不间接将 event.key 属性批改为 null？那是因为在一些浏览器中，event 事件对象是 readOnly 只读的，无奈批改，严格模式下批改只读对象还会报错。
————
02.20. IE11 保留大额数据时 Storage 事件将不会响应
问题形容：https://stackoverflow.com/que…，在 IE11 中 localStorage 保留大额数据时，会呈现 Storage 事件不响应的状况，在 StackOverflow 页面写着 ” 大额数据 ” 的临界值是 4282(单位字节)，但 XJ 测试却发现不一样，阐明临界值在不同环境下是不一样的，甚至是在同个环境下还可能会呈现动态变化的状况，并且这个临界值是 event.oldValue 属性和 event.newValue 属性相加的后果，也就是说可能在创立时因为 event.oldValue 属性为 null，所以事件会响应，但之后 event.oldValue 属性和 event.newValue 属性的字节数相加超过临界值了，Storage 事件就不响应了，如果超过了临界值，不单 setItem() 操作不响应，removeItem() 操作也不会响应，但 clear() 操作总是会响应，惟一值得庆幸的是 sessionStorage 的操作并不会呈现这种状况。
解决方案：在 StackOverflow 页面也有提到，就是革新 setItem() 和 removeItem() 办法，创立一个两头的代理键值对进行响应，代理键值对保留着被操作的指标键值对的 key 值，因为代理键值对比拟小，总是会响应，当响应的时候通过它的值就能够晓得是操作了哪个指标，以此来解决事件不响应的状况，实际上 XJ 在 xj.storage 插件中也曾尝试过应用这种办法，然而最初还是放弃了，因为这种形式尽管能解决不响应事件的问题，却无奈获得这个大额数据最新的后果值，因为此时的 event.newValue 属性是代理键值对的最新后果值，而在事件回调中应用 getItem() 办法获取大额数据以后的后果值，因为 IE 的事件回调存在异步，所以也是不精确的，在无奈失去最新后果值的状况下，即便响应了事件，也没有什么意义，实际上这也是这么多 BUG 中 XJ 惟一一个没有妥善计划能解决的问题。
参考内容
MDN – Web Storage API
MDN – 应用网络存储 API
array_huang – localstorage 必知必会
kidney – localStorage 存满了怎么办？
博客园 : awen – localStorage 变更事件当前页响应新解
Feross Aboukhadijeh – 介绍 HTML5 Hard Disk Filler™ API
dev-test.nemikor – 在线测试浏览器的 Storage 的最大存储量
StackOverflow – 为什么 IE 会在存储数据的窗口也触发 Storage 事件
StackOverflow – Safari(MacOS) 也会在存储数据的窗口触发 Storage 事件
StackOverflow – IE11 在一次性存入大额数据的时候将不会触发 Storage 事件
相干插件 – marcuswestin – store.js
相干插件 – Mozilla – localForage
相干插件 – andris9 – jStorage
XJ.Chen – xj.storage