先来几道面试题
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 过于脆弱，而且还会影响请求的效率。
那降级到 url 上呢？很麻烦。比如有一个交互流程是这样的：页面 A => 页面 B => 页面 C，如果页面 A 的数据要传到页面 C，就得通过页面 B 做一层中转。而且 url 长度也是有限制的。
单页应用解决跨页面传数据就很简单，改造成单页应用呢？这个就得估算成本，看老板们认不认可了，而且原有应用积累了大量的业务逻辑，没有注释，没有测试用例，需求文档散落在不知名的角落，你真能保证重新做的和原来的功能一模一样吗。
我们还可以求助客户端同学，通过 js bridge 提供一个仿 localStorage 的东西，不过要考虑版本的问题，新版 app 里使用了客户端提供的 store，怎么兼顾老版 app，而且还要考虑兼容浏览器、微信。所以这种方案也只能解决一部分问题。
我们还可以求助后端同学，多加几个字段甚至多加几个接口，不过这涉及到核心业务流程的改造，风险不小，而且不见得能完全解决问题。
我们还可以来一招互相伤害大法，那就是把别人存的东西都删掉。。。
localStorage 是个好东西，不用，这是因噎废食，用，又很难统一和约束各业务线的用法，跟你在同一个域名下做开发的人可能跟你不在同一栋楼，甚至可能不在同一个城市。一旦放开用，就总会面临存满的风险。
问题的根源
同一个域名共享同一个 localStorage，而同一个域名下存在过多独立的业务线，业务线之间各自为政，毫无节制的攫取公共资源，这就是 localStorage 溢出问题的根源。
就我观察的情况来看，很多公司都喜欢把 h5 页面挂在 i.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 无限膨胀的问题。
如果我是架构师
我们在工作中肯定会遇到前人留下的各种坑、早期技术方案问题积累下的各种技术债、各种团队间合作问题、各种环境问题...，吐槽不会产生任何价值，能够产生价值的是这样一个问题：如果当初我是架构师，我怎么做技术方案来避免这一切问题？好的架构师总是能让技术方案提前一点等候着业务，而不是让业务追着、拖着、逼着走。这就是经验的价值。