背景1：
通常，前端的资源文件加载优化，就是在文件不修改迭代的情况下，尽可能多地利用缓存，避免多次下载同样的文件。
一般的做法就是尽量延长资源的有效期，也就是设置 Cache-Control 里的 max-age，使页面资源请求为 304，直接使用本地缓存。
但是手机端由于个人习惯，网络原因等，协商缓存（304）的效果就没 pc 端那么好了。
所以，localStorage 出场。
localStorage 相比 cookie，可以缓存大体积的数据，而且永久有效。
技术难点：
只要一个项目还在迭代开发，就难以避免需要更新资源文件。
普通的资源请求，可以根据文件名+md5，或者在资源链接后面加上特定的后缀做为标识来判断是否需要更新资源。
http://res.wx.qq.com/mmbizwap/zh_CN/htmledition/js/biz_wap/moon32ebc4.js
http://1.ss.faisys.com/js/comm/fai.min.js?v=201612051739
对于 localStorage 缓存，则需要一套新的缓存更新机制。
同时需要搭建更新代码的脚手架？来管理资源文件的读取和写入。
后台输出一份资源配置信息。（后台输出一份依据给前端做判断用，是否使用缓存或重新发起请求，下载最新的资源文件。）
存在 XSS 安全隐患，我们知道，localStorage 可以任意修改。
举个栗子：微信判断该版本是否最新，就是用控制台中的 value 值与后台输出的配置信息进行比较，最后得出是否更新的结果，一致则使用缓存。
微信 localStorage ：
微信资源配置信息会在脚手架 moon.js 之前输出：
控制台输出 window.moon_map：
简单应用：
背景2：token
结论：
非首屏渲染需要的 css 文件，可以做LS缓存（首屏需要SEO，爬虫爬取，故常规输出）
移动端推荐LS缓存。
扩展：