本文以字节跳动的微前端项目运行时隔离任务出发，深入讲解sandbox（后称沙盒）的技术实现，以及上述实际实现过程中一些发生过的问题。把一些关键细节和多年的采坑经验充分的分享给读者，希望能对大家有一些帮助和启发。至于对微前端的整体思考，可以参考：《前端微服务在字节跳动的打磨与应用》，希望读者在读本文之前已经有所了解。
1.沙盒应该做什么首先从沙盒对微前端乃至前端的意义开始讲起。沙盒对软件工程来说其概念不算是新鲜事物，仅看前端对隔离的需求也由来已久。并且根据不同的实际业务场景，已经有过非常多和有特色的探索。
古老的Iframe一切都从iframe开始讲起了，反正是个看上去很美的解决方案。没有真的用过的人肯定都会这样想象。但有些可能等到你要真的搞一个通过iframe全面聚合的才知道。单纯的iframe聚合非常麻烦，需要很多补漏的劳动量。
旧的iframe的方案可以在一定程度上解决了耦合问题。具体是把一个站点页面拆成N个frame，每个frame单独跑一个独立的域名。
它的好处非常清楚，独立上下，独立运行，谁都不会妨碍谁。但是是不是这样沙盒就完成了呢？这样算不算沙盒就不好说了，会有很多不同的观点和理论。比如一些观点可能会觉得沙盒不是像这样全独立，而是以隔离模拟独立。后面我们会再次谈到这个观点，并从实现角度分享一些我们的思考成果。
因为一个完整的项目包含大量公用的功能和代码，例如登录身份、站内信，业务模块只是其中的一个部分。这部分完全用跨window通信实现起来很费时费力，并且单页应用了React或类似的加载技术展示之后，iframe的效果也逊色很多。想要突破这些限制，困难就很多了。
古老的困难第一点不用多说各位都会想到deeplinking的问题，对吧，至少这点得做到才能算是一个工程，尤其MVC时代以来路由一直非常重要。
还有就是各种共享的东西，比如登录怎么共享。iframe当然也不是不行。和前面后面提到的诸多问题一样都不是不行、而是很麻烦，要针对他去解决很多困难。从效果上讲，最终也完全可以形成一个不错的iframe沙盒。
另一显然的困难是，组件库、组件风格的父子传递，以及ReactVUE等渲染引擎的底层代码、内存对象的传递。初步的实现是加入分片打包功能，拆