由 dawei 应用沙箱可能是微前端技术体系里面最有意思的部分。一般来说沙箱是微前端技术体系中不是必须要做的事情，因为如果规范做的足够好，是能够避免掉一些变量冲突读写，CSS 样式冲突的情况。但是如果你在一个足够大的体系中，总不能仅仅通过规范来保证应用的可靠性，还是需要技术手段去治理运行时的一些冲突问题，这个也是沙箱方案成为微前端技术体系的一部分原因。
首先纵观各类技术方案，有一个大前提决定了这个沙箱如何做：最终微应用是单实例 or 多实例存在宿主应用中。这个直接决定了这个沙箱的复杂度和技术方案。
单实例：同一个时刻只有一个微应用实例存在，此刻浏览器所有浏览器资源都是这个应用独占的，方案要解决的很大程度是应用切换的时候的清理和现场恢复。比较轻量，实现起来也简单。
多实例：资源不是应用独占，就要解决资源共享的情况，比如路由，样式，全局变量读写，DOM。可能需要考虑的情况比较多，实现较为复杂。
最开始我们的想法是：
从业务场景：我们可能存在的情况是当用户操作一个产品 A 的同时和另一个产品 B 发生了关联操作，需要唤醒应用 B 做操作。虽然从产品维度可以规避掉，比如先切到 B，然后切回 A，但是从某种程度上因为技术的原因，我们限制了产品交互的发挥。
从技术角度：解决了多实例当然单实例的场景也不在话下，并且单实例的方案某种程度上给编码上带来了一定复杂度，比如业务代码需要自己做业务上下文的切换。
最近 qiankun 2 也转变了思路，从单实例的支持到开始支持多实例，多多少少也侧面说明了，多实例是一个值得投入和技术攻克的场景。