localstorage
一般用于在前端缓存一些数据时使用，这些数据一般是只在前端使用，而后端不使用的，所以不用每次都往后端发送。（或是前端做统计，后端只要一个统计结果之类的）
其他的比如 web SQL、IndexedDB 两个数据库，这一般是用来做 HTML 5 应用的时候才会用到的。比如 PWA 或是 HTML5 页游之类的。
前端开发的时候，在网页刷新的时候，所有数据都会被清空，这时候就要用到本地存储的技术，前端本地存储的方式有三种，分别是cookie，localstorage和sessionStorage ，这是大家都知道的。
sessionstorage
使用localStorage必须了解的点
本地存储满了之后，浏览器是什么样的行为？
本地存储容量有限，因此宝贵，那么就整个站点而言，使用本地存储的策略是什么？
实际编码过程中，本地存储又有那些注意事项？
整站本地存储的规划
客户端的存储空间宝贵，然而站点也因为业务的不同，很难有一个统一的实施细则，但是有几个大原则不会变。
一、只保存重要页面的重要数据：①典型的，首页首屏；②对业务庞大的站点，这点尤其重要。二、①极大提高用户体验的数据，比如表单的状态，可以提交之前保存，当用户刷新页面时可以还原；②静态资源，比如 js 和 css。三、一个请求一个 key 值（一个 cgi 一个 key 值）。避免请求链接加参数的 key (http://request-ajax.cgi[params])，这样必然让 key 值趋于冗余从而撑爆空间
localStorage缓存应用的场景
1. 非首屏渲染需要的css文件，可以做LS缓存。
首屏渲染需要的css，需要按常规方式输出，因为SEO需要，不然爬虫爬取页面的时候，页面效果会很不好。而非首屏的css，则可以用LS缓存，减少资源下载时间。
2. 展示类、动画类等非业务主要逻辑的代码，可以做LS缓存。
这样，可以一定程度上避免业务层的安全漏洞。当然，前端再怎么做防护都是一层薄纸。重要的，还是后台接口要做好安全保护。
3. 移动端可以做LS缓存。PC端做LS缓存，起到的优化作用不大。
cookie、localStorage和sessionStorage，三者的异同
生命周期：cookie：可设置失效时间，没有设置的话，默认是关闭浏览器后失效；localStorage：除非被手动清除，否则将会永久保存。sessionStorage： 仅在当前网页会话下有效，关闭页面或浏览器后就会被清除。
http请求：cookie：每次都会携带在HTTP头中，如果使用cookie保存过多数据会带来性能问题。localStorage和sessionStorage：仅在客户端（即浏览器）中保存，不参与和服务器的通信
易用性：cookie：需要程序员自己封装，源生的Cookie接口不友好。localStorage和sessionStorage：源生接口可以接受，亦可再次封装来对Object和Array有更好的支持
应用场景
从安全性来说，因为每次http请求都会携带cookie信息，这样无形中浪费了带宽，所以cookie应该尽可能少的使用，另外cookie还需要指定作用域，不可以跨域调用，限制比较多。但是用来识别用户登录来说，cookie还是比stprage更好用的。其他情况下，可以使用storage，就用storage。
localstorage 的优点
在知乎对于该问题的回答中，最激烈的反对意见是这样的：浏览器都帮你缓存好了，干嘛多此一举缓存到 LS 里？
对于 css/js 传统的优化方法，最常见的便是将小的静态文件直接 inline 减少请求，大的文件、甚至全站都完整的接入 CDN，直接将文件就近推送以加快加载速度。
CDN 除了可以就近分发，还可以设置缓存头提示浏览器缓存一些静态文件，这样当页面二次加载便不需要发起 HTTP 请求。但是，外链资源即使合理配置了强缓存头，浏览器依然会在用户主动刷新时发起协商请求（响应码通常是 304，虽无响应正文，但依然需要建立连接）；会在强刷时发起 cache-control:no-cache 和 pragma:no-cache 的 Request Header，忽略所有缓存，触发服务端的 200 响应。虽然用户不一定都会强制刷新，但在网络环境较差的环境下，使用 304 协商响应依然颇花费时间。
所以，使用 localstorage 等效于无视用户主动刷新行为的本地强缓存，而且可以存储较大体积的数据（最小是 2M），而且永久有效。如果把 js 和 css 存储在 localstorage 中，可以省去发送 HTTP 请求从而改善用户的浏览体验。
localstorage 的缺点
而且移动端由于存储大小问题，手机浏览器的缓存经常会被清理，但 localstorage 被清理的几率会低一些。当然，使用 localstorage 最大的问题，在于 XSS 的安全问题。一旦用户的 localstorage 被篡改，那么危险将会是持久的，即使漏洞已经被修复。这是由 localstorage 的生命周期决定的。
我的观点
localStorage 作为一种持久性的存储容器，可以有效代替强缓存机制。浏览器缓存可能被清空，冷缓存可能会被热点文件挤出浏览器的缓存池，但是 localStorage 的存储毕竟是长久的，所以用来存储一些本身不需要经常更新的文件并不为过。
虽然有的人吐槽和质疑说手动实现一个操作 localStorage 的读写和更新机制不过是浪费时间，因为浏览器本身就已经有一整套 Cache Control 机制；但是你不得不承认，浏览器的 Cache 的操作就像一个黑盒，你不能控制它；如果你设置错了 cache control header，有可能会导致致命和后果。给 URI 添加 query 来控制缓存版本的方式不仅 dirty 而且是在浪费 CDN 和用户本地的存储空间。
虽然使用 Service Worker 操作 Cache Storage 解决了上述的问题，但是就目前来看，localStorage 的兼容性比 Service Worker 更好，而且缓存效果也更好。在已经有了相对成熟的 lsloader 和相关 API 来操作 localStorage 时，我倾向于在我的项目中使用 localStorage 作为缓存机制。
小结
CDN 方案是加速静态文件访问的一种优秀方式，但是必须要面临缓存刷新和 CDN 的压力、回源的压力的问题。
localstorage 是优秀的强缓存方案，因为 localstorage 被清空的概率不大。但是要专门注意安全问题。SRI 和 CSP 都是不错的保护 localstorage 里的代码的方案。
所以，localstorage 的方案适合以下情况：
同域下的每个页面都会用到的、频繁请求的文件
文件本身不需要经常更新，如 jQuery、一些字体
为移动端或较差网络环境下的特殊加载优化
降低源站和 CDN 的压力
用 base64 存储一些小的图片减少请求并缓存
网友评论