1.什么？你还不会 OpenTiny 跨框架组件库适配微前端？
2.微前端框架 之 qiankun 从入门到源码分析
3.qiankun 2.x 运行时沙箱 源码分析
4.微前端学习笔记(3):前端沙箱之JavaScript的微前sandbox（沙盒/沙箱）

什么？你还不会 OpenTiny 跨框架组件库适配微前端？

       本文由体验技术团队陈家梅同学分享，带你手把手实现 TinyVue 组件库适配微前端~

       以下是端源我对微前端的一些粗浅理解，对微前端有一定了解的码微码话可以略过，直接进入第二部分。前端

       微前端是实现什么？我们首先来点熟悉的东西，以我们最常见的及代mongodb开发源码页面为例，看下图：

       左侧为子应用路由切换，微前通过点击左侧完成右侧页面子应用的端源切换，这就是码微码一个最简单的微前端应用架构了。

       作为一名资深打工人，前端为了便于理解，实现我把微前端类比成一家企业，及代当它发展到了一定规模时，微前效率会变得低下，端源运行迟缓。码微码此时为了便于管理，提高能效，加强部门之间的协作；一般会分化出几家子公司 + 一个总公司（或总部）。

       其特点是：每家子公司都可以独立运作，也可以互相协作，但都听从总部的统一管理，至此，我们就有了微前端的基本概念。

       微前端借鉴了后端比较成熟的微服务概念：

       为什么需要微前端，它有什么优点？一个优秀的微前端框架应当有如下优点：

       应用之间互相独立：包括了 js 沙箱、css 隔离等；

       支持父与子，子与子应用之间的通讯；

       性能方面支持预加载和按需加载机制；

       多个公共依赖的共享处理。

       一个优秀的前端工程像一家优秀的企业一样，当项目的业务达到了一定的规模，高度集成为一个巨无霸，850镜像源码为了降低运行消耗、维护的时间和人力成本，提升用户的终端体验；拆分+整合就势在必行了。

       想象一个场景：（作为一名刚入职公司的前端工程师，不管你是初级还是资深，面对使用不同技术栈、相互之间业务耦合性大的多个项目；或者是一个高度集成、体量庞大，运行缓慢的巨石项目，你要怎么处理才能降低项目维护成本，提升性能，从而提升效率，提升用户体验？）

       第一种情况：项目多且杂我就遇到过，工程师们加班加点的修 bug；但愣是换了一批又一批人，还是没有改善现状，进入了一个恶性循环）。

       所以我们急需一种能整合所有项目，并且单个项目又能独立运作的技术方案。

       此时有条件的研发团队，一般都会选择微前端，接入同一套主系统，既能独立运行又可相互通信，兼顾了流畅体验和信息共享。

       在选择了一款优秀的微前端架构的前提下，需要注意：此时组件库的选择就能展现出工程师眼光的差距了；是有 n 种前端框架就使用 n 个组件库好，还是 n 种前端框架就使用一个组件库好呢？

       我比较懒、想节省时间、想早点下班...... 而且一套东西越用越熟练，效率越高，tolowercase的源码不拘泥于技术栈，可以一当十（想当年六大门派围攻光明顶，我张无忌以一当......额，回归正题），至此 @opentiny/vue 就成了我不二之选。

       那么如何做？

       我们需要用 @opentiny/vue 组件库，在各个子应用中引入并使用，共用一套 @opentiny/vue-renderless 方法，实现多个技术栈跨端引用。

       经过多方对比，我们选择了目前比较合适的（无界）微前端框架，接入相对简单，并兼具一款优秀微前端框架的优点。

       跟着我们一起来动手吧！

       为了实现跨框架使用 @opentiny/vue 组件库，我们需要进行以下步骤：

       1. 使用 pnpm 管理组件库工程和微前端工程

       2. 创建 monorepo 工程根目录，使用 gitbash 输入以下命令（以下所有命令均在 gitbase 环境下运行）：

       3. 创建组件源代码目录：

       4. 在根目录下创建 package.json，并修改其内容：

       5. 定义包管理工具和一些启动工程的脚本：

       6. 解决一些 pnpm 针对 Vue 不同版本（Vue2、Vue3）的依赖冲突，packageExtensions 项可以让 Vue2 相关依赖可以找到正确的 Vue 版本，从而可以正常加载 Vue2 和 Vue3 的组件。

       7. 在根目录创建配置文件 pnpm-workspace.yaml，文件内容如下：

       至此初始化已经完成，我们总共完成了四件事：

       项目配置基本完成，我们就可以开始将注意力集中于编写我们的页面了。

       在开始创建之前，前面我们已经了解了四个子工程的项目结构，那就有思路了：

       1. 使用 vite 脚手架创建一个 Vue3 的工程，运行命令如下：

       2. 下载安装无界微前端的多年指标源码 Vue3 依赖包和 vue-router 路由：

       3. 进入主工程，在 packages/home/src 下新建 views 文件夹，并在文件夹中创建一个主页面和四个子页面，分别为：Home.vue（主页--集成页面）、React.vue、Solid.vue、Vue2.vue、Vue3.vue 为四个子页面

       4. 按照相似步骤创建四个子工程，分别使用 React、Solid、Vue 的 vite 套件创建。

       5. 配置四个子工程vite.config.js，设置不同的端口号。

       6. 分别在四个子工程里使用 button 组件和倒计时 countdown 组件，自定义一些交互逻辑。

       7. 启动创建好的微前端，效果如下图所示：

       8. 总结步骤，创建 setup.js 文件，通过脚本一键启动所有微前端工程。

       整个工程搭建流程清晰，通过适配 @opentiny/vue 组件库，实现了跨框架组件库的使用，简化了开发流程，提升了开发效率。

       最后，我们对整个微前端架构有了深入的理解，也体验了从零到一搭建微前端工程的全过程，从中感受到了微前端架构的灵活性和组件库选择的重要性。@opentiny/vue 组件库以其灵活、高效的源码app购买特点，为跨框架开发提供了便利，降低了维护成本，提升了用户体验。欢迎进入 OpenTiny 开源社区，一起参与技术交流和贡献，共建前端开发的未来。

微前端框架 之 qiankun 从入门到源码分析

       微前端框架 qiankun 是单页应用框架single-spa的优化版本，它旨在解决single-spa在构建微前端架构时遇到的问题，如强侵入性打包和状态维护的不足。理解qiankun前，最好先对single-spa有深入认识，以便带着问题去剖析源码。

       single-spa虽然简单，但存在几个显著问题，如需将微应用打包成单个JS文件，影响了打包优化，且微应用发布时配置调整频繁。qiankun通过二次封装，解决了这些问题，使得微前端的构建和维护更为便捷。

       qiankun 2.0.版本的源码分析全面深入，其优势在于提供了完整的示例项目和解决方案，避免用户重复踩坑。文章按主题拆分，让你逐步理解框架结构、主应用配置和微应用接入。源码中，loadApp方法被认为是核心，涉及样式隔离、通信机制等内容。

       通过本文，你将学会如何从零开始使用qiankun，以及如何解析其内部实现。继续深入研究，你可以探索样式隔离的两种方式、预加载策略以及应用间通信机制。阅读qiankun源码可能需要反复阅读和讨论，但定会有收获。

       最后，文章已收录到GitHub，你可以通过关注微信公众号获取最新更新。感谢您的点赞、收藏和评论，期待下期内容的互动。学习如溪水长流，成为习惯，知识自然成常。

qiankun 2.x 运行时沙箱 源码分析

       当学习成为日常，知识渐成通识。在这里，我们将深入剖析qiankun 2.x 中的运行时沙箱技术，它在微前端世界中扮演着重要角色。qiankun 基于single-spa的封装，解决了微前端中的隔离问题，特别是针对全局对象污染的挑战。

       沙箱，作为网络安全中不可或缺的工具，为不受信任的文件或应用提供一个隔离环境。在微前端中，它旨在为每个微应用创建一个独立、纯净的运行空间，确保切换应用时全局对象的纯净性。其中，JS 沙箱通过proxy代理window对象，记录其属性操作，微应用则在proxy上执行，避免直接对全局对象污染。

       样式沙箱则是通过增强createElement和相关DOM操作，控制script、link、style标签的创建和添加，确保样式隔离。在微应用卸载时，它能清理缓存的动态样式，并在重新挂载时恢复。尽管严格样式隔离模式和scoped css也能提供样式隔离，但样式沙箱在此基础上提供了额外的管理功能。

       深入源码，如createSandboxJS、SingularProxySandbox等函数，虽然代码复杂，但理解其工作原理后，你会发现运行时沙箱的逻辑其实相当精妙。为了更好地探索，欢迎访问github仓库，关注patchAtBootstrapping、patchDocumentCreateElement等关键部分。

       最后，再次感谢大家的参与和支持。我们下期将继续分享更多关于qiankun运行时沙箱的深入剖析，期待你的关注和反馈。在微信公众号李永宁lyn，我们会第一时间分享新内容，同时也欢迎star和watch我们的文章。

微前端学习笔记(3):前端沙箱之JavaScript的sandbox（沙盒/沙箱）

       沙盒（Sandbox）机制旨在确保代码的安全性，限制其权限以防止恶意或不受信任的脚本访问敏感资源或干扰其他程序执行。通过在沙盒环境中运行代码，可以将其行为限制在安全范围之内。

       沙盒是一种隔离机制，允许程序在独立环境中运行，避免对外界程序造成影响，保障系统安全。在开发中，沙盒环境通常用于服务器中通过Docker创建容器，或在 Codesandbox中运行代码示例，以及在程序中执行动态脚本。

       微前端框架主要负责两个工作：一是实现JS沙盒，二是将沙盒内的执行结果输出为WebComponents，插入到页面中。

       沙盒能够确保每个前端应用拥有独立的上下文环境、页面路由和状态管理，避免相互干扰。

       实现JavaScript沙盒的方法有两类：通过iframe或ShadowRealm在原生环境上实现，以及利用JS特性（主要基于Proxy）实现。

       利用iframe实现沙盒是通过其天然的隔离机制和postMessage通讯机制。在iframe中运行的脚本只访问当前iframe的全局对象，不会影响父页面功能，提供简单、安全的实现方式。腾讯的无界沙箱采用此方案。

       使用iframe沙盒有一些限制，需要配置来解除限制。实际工程中，可以参考《让iframe焕发新生》一文，使用封装的框架wujie实现。

       无界沙箱模式在一张页面上激活多个子应用，利用iframe独立执行，并通过location和history管理路由，支持浏览器前进、后退操作。

       核心点包括：iframe数据劫持和注入、iframe与shadowRoot副作用处理。实现细节在无界源码中。

       ShadowRealm是一个ECMAScript标准提案，允许创建多个高度隔离的JS运行环境，具有独立的全局对象和内建对象。但目前仍处于提案阶段。

       WebWorker提供独立线程作为沙箱环境，适合作为底层实现，但不常提及。腾讯无界方案展示了其优势。

       IIFE（立即执行匿名函数）实现简易沙箱，可限制变量访问，但只能实现基本隔离。

       with + new Function提供访问全局变量和局部变量的能力，但存在全局作用域污染风险。

       利用with和Function结合Proxy实现ES6 Proxy，通过拦截器get和set对window进行代理，实现全局环境的隔离。

       沙箱逃逸是极端情况下的安全挑战，通过设置Symbol.unScopables为true来绕过with作用域限制。

       沙盒实现包括简单代码实现和多实例模式，分别通过with块和Proxy对象隔离执行环境。单实例模式只支持记录变化，多实例模式则在微应用间创建独立的沙箱环境。

       基于属性diff的沙箱机制在不支持ES6的环境中使用普通对象快照实现存储与恢复，用于更新子应用环境。qiankun中提供了此降级方案。

       总结：沙盒机制是实现代码安全隔离的有效手段，通过不同方法实现沙箱，可以满足不同场景的需求。在实现时需考虑限制与优化，确保安全性和性能。