先来几道面试题
1、a.meituan.com 和 b.meituan.com 这两个域能够共享同一个 localStorage 吗？
2、在 webview 中打开一个页面：i.meituan.com/home.html，点击一个按钮，调用 js 桥打开一个新的 webview：i.meituan.com/list.html，这两个分属不同 webview 的页面能共享同一个 localStorage 吗？
3、如果 localStorage 存满了，再往里存东西，或者要存的东西超过了剩余容量，会发生什么？
答案
1、同一个域名（document.domain）共享同一个 localStorage，a.meituan.com 和 b.meituan.com 是两个域名，所以不能共享
2、能。相当于同一个浏览器的不同标签页。不同浏览器之间不能共享。
3、存不进去并报错（QuotaExceededError）
技术很简单，业务很麻烦
在大公司，同一个域名下可能存在几十上百条业务线，每条业务线都可能因为各种理由往 localStorage 里塞东西，跨页面传数据啦、缓存啦、离线化啦、性能优化啦...，5M 看起来很多，其实很快就用完了。而开发时基本无感知，是因为大家都只访问自己的业务，但用户会访问各种业务，时间一久，很容易就存满了，凡是严重依赖 localStorage 的业务流程都存在风险，写可能出问题，读自然也会出问题。
一种容易想到的方案是，当 localStorage 存满后降级到 sessionStorage 里。看上去没啥问题，但实际业务中 app 内 h5 页面跳转常常采用新打开 webview 的方式，这么做的好处是关闭一个 webview 可以直接回到上一个页面，而不用重新加载页面，对于订单填写这类带有状态的页面就很需要这么做。新打开 webview 等于新打开一个会话，而 sessionStorage 只能存在于同一个会话中，因此 sessionStorage 无法跨页面共享。
那降级到 cookie 里呢？cookie 一共才 50 个，总大小不超过 4k，作为 backup 过于脆弱，而且还会影响请求的效率。如果后端对请求头大小做了限制，还可能产生 413 错误，导致请求被拦截。
那降级到 url 上呢？很麻烦。比如有一个交互流程是这样的：页面 A => 页面 B => 页面 C，如果页面 A 的数据要传到页面 C，就得通过页面 B 做一层中转。而且 url 长度也是有限制的。
单页应用解决跨页面传数据就很简单，改造成单页应用呢？这个就得估算成本，看老板们认不认可了，而且原有应用积累了大量的业务逻辑，没有注释，没有测试用例，需求文档散落在不知名的角落，你真能保证重新做的和原来的功能一模一样吗。
我们还可以求助客户端同学，通过 js bridge 提供一个仿 localStorage 的东西，不过要考虑版本的问题，新版 app 里使用了客户端提供的 store，怎么兼顾老版 app，而且还要考虑兼容浏览器、微信。所以这种方案也只能解决一部分问题，当然，如果 h5 的流量绝大多数都在 app 里，那么这种方案是可以解决一大部分问题的，不过客户端提供的存储可不见得比原生的存储可靠，还是得加 backup。
我们还可以求助后端同学，多加几个字段甚至多加几个接口，不过这涉及到核心业务流程的改造，风险不小，而且不见得能完全解决问题，也无法永久的解决问题。
我们还可以来一招互相伤害大法，那就是把别人存的东西都删掉。。。
localStorage 是个好东西，不用，这是因噎废食，用，又很难统一和约束各业务线的用法，一旦放开用，就总会面临存满的风险。跟你在同一个域名下做开发的人可能跟你不在同一栋楼，甚至可能不在同一个城市，你有那个影响力去统一所有人的使用规范吗。
还有一个很讨厌的事情：safari 在隐私模式下不支持 localStorage 的存取（ios11 以下），这种情况比较罕见，但如果出了客诉，也是个大坑。
问题的本质
localStorage 归根结底就两个作用：持久化存储与跨页面传数据。持久化存储不会出问题，存不进去就存不进去呗，取不出来就去其它地方取，或者不取。问题就出在跨页面传数据上，上一个页面因为 localStorage 存满导致数据没有写入，下一个页面读取数据为空，从而导致错误。
问题的根源
同一个域名共享同一个 localStorage，而同一个域名下存在过多独立的业务线，业务线之间各自为政，毫无节制的攫取公共资源，这就是 localStorage 溢出问题的根源。
就我观察的情况来看，很多公司都喜欢把 h5 页面挂在 i.xxx.com 或 m.xxx.com 下，然后通过路径划分业务，比如 i.xxx.com/project-a, i.xxx.com/project-b...，随着业务发展，越来越多的业务都加到 i.xxx.com 中，“公地悲剧”就无可奈何的产生了，而且积重难返。我以前在的团队也是如此，用 h5、js、css 这样的类型名称来划分目录，初期东西少，自然没问题，但后来所有应用都把资源塞到 js 文件夹、css 文件夹下，一个文件夹包含了来自五湖四海的上百个文件，维护起来十分难受。
通过应用类型划分，而不是通过业务类型划分，这是最初架构策略的问题。如果 a 业务挂在 a.xxx.com 下，b 业务挂在 b.xxx.com 下，每个业务有独立的团队维护，localStorage 从公共资源变成团队的私有财产，或许这样才能从根源上解决 localStorage 无限膨胀的问题。有网友提出对 i.xxx.com 进一步划分子域，其实也是这个思路。
理想的方案
假设我们回到起点，从零建设前端工程，我们怎么避免 localStorage 存满的问题？
1、划分域名。各域名下的存储空间由各业务组统一规划使用
2、跨页面传数据：考虑单页应用、优先采用 url 传数据
3、最后的兜底方案：清掉别人的存储
互相伤害其实是个好办法
在已然发展很久的业务中，我们怎么解决此问题呢？
const QUOTA_EXCEEDED_ERR_CODE = 22
function write (key, data) {
try {
localStorage.setItem(key, data);
} catch (e) {
if (e.code === QUOTA_EXCEEDED_ERR_CODE) {
localStorage.clear();
localStorage.setItem(key, data);
}
}
}
上面这个方法还是有点问题，因为它把自己业务要用的东西也给删了，所以自己的业务最好统一在 key 上加一个前缀，清空 localStorage 时只删别人的。
有的同学可能会担心，这样会不会对其它业务造成伤害？或者产生一些难以发现的 bug。其实这种担心很大程度上是因为忽略了实际的使用场景。用户用同一个设备打开同一个 app，在同一个时间只能访问一个业务，因此不会存在某个业务正在使用过程中，localStorage 被其它业务清掉的场景，除非！除非有交叉的业务场景。
没有银弹，没有十全十美的方案。
补充
掘金网友@FE 提出用 indexedDB 存文件类型的数据，localStorage 存业务数据，这是一种可以缓解问题的方案
本文转自：https://www.cnblogs.com/kidney/p/9058352.html