https://blog.csdn.net/qq_41694291/article/details/113842872
答题分为以下几点
- 什么是微前端，为什么要用（解决什么问题）
- 优势
- 常见的微前端方案有哪些
- 我们用的是哪个微前端方案
- qiankun与single-spa相比好在什么地方
什么是微前端，为什么要用（解决什么问题）
概念：微前端的概念借鉴于后端的微服务，一般以业务功能为拆分单元
解决问题：大型项目的变更、扩展、维护困难的问题
优势
- 技术兼容性好、子应用可以基于不同的技术框架
- 拆分后体积变小，代码内聚性更强，每个子应用只是一个业务模块
- 能够独立开发、编译、部署
- 耦合性低，可独自开发，互不干扰
- 可维护和扩展性好，可专门升级某一个功能
缺点
总体积变大，插件可上传cdn，但公共函数资源不便于共享
常见的微前端方案有哪些
iframe：隔离性和兼容性好，性能和使用感差（性能差因为不会有缓存，每次重新加载）
基座模式：基于路由分发，由基座监听路由变化，加载不同的应用，实现应用解耦，single-spa、qiankun
组合式集成：组件单独打包发布，类似于npm包
EMP：主要基于Webpack5 Module Federation
web components：micro-app(京东的)
Web Components
微前端（Micro Frontends）是一种前端架构风格，通过将大型单体应用程序分解为一组小型、自治的功能块，来提高应用程序的可维护性、可扩展性和可重用性。
Web Components 是一组浏览器标准和 API，允许开发者创建可重用的自定义 HTML 元素和组件。它由三个主要技术组成：Custom Elements、Shadow DOM 和 HTML Templates。Web Components 提供了一种用于封装和复用 HTML、CSS 和 JavaScript 的机制，类似于 React 和 Vue 等现代前端框架提供的组件化机制。
微前端和 Web Components 的结合，即为微前端 WebComponents。在微前端 WebComponents 架构中，每个小型功能块都被打包为一个 Web Component，这些 Web Components 可以独立开发、测试和部署。在运行时，这些 Web Components 被加载到一个主应用程序中，以组成一个完整的应用程序。这种架构风格使得应用程序更易于扩展、升级和维护，同时也可以提高开发效率和团队协作能力。
微前端 WebComponents 架构中的主应用程序负责加载和管理所有子应用程序，同时还提供了一些公共的基础设施，例如路由、状态管理和通信机制等。每个子应用程序都是一个自治的 Web Component，它们可以使用任何前端框架或库来实现功能，甚至可以使用不同的技术栈来开发。在运行时，这些子应用程序可以被独立部署和升级，不会影响到整个应用程序的稳定性和可用性。
micro-app
https://juejin.cn/post/7210747150815936569#heading-35
micro-app并没有沿袭single-spa的思路，而是借鉴了 WebComponents 的思想，通过 CustomElement 结合自定义的 ShadowDom，将微前端封装成一个类 WebComponents 组件，从而实现微前端的组件化渲染。并且由于自定义 ShadowDom 的隔离特性，micro-app不需要像single-spa和qiankun一样要求子应用修改渲染逻辑并暴露出方法，也不需要修改 webpack 配置，是目前市面上接入微前端成本最低的方案。
为什么不用iframe
iframe 最大的特性就是提供了浏览器原生的硬隔离方案，不论是样式隔离、js 隔离这类问题统统都能被完美解决。但他的最大问题也在于他的隔离性无法被突破，导致应用间上下文无法被共享，随之带来的开发体验、产品体验的问题。
- url 不同步。浏览器刷新 iframe url 状态丢失、后退前进按钮无法使用。
- UI 不同步，DOM 结构不共享。想象一下屏幕右下角 1/4 的 iframe 里来一个带遮罩层的弹框，同时我们要求这个弹框要浏览器居中显示，还要浏览器 resize 时自动居中..
- 全局上下文完全隔离，内存变量不共享。iframe 内外系统的通信、数据同步等需求，主应用的 cookie 要透传到根域名都不同的子应用中实现免登效果。
- 慢。每次子应用进入都是一次浏览器上下文重建、资源重新加载的过程。
我们用的是哪个微前端方案
我们采用的是qiankun，主要思路是将一个大应用，拆分为更小的、可独立开发、测试、部署的子应用。
传统的大型项目：所有模块都在一个应用里，由应用本身负责路由管理，属于应用分发路由方式
拆分微应用的项目：属于基座模式下的系统架构，各应用互相独立，单独运行在不同的服务上，基座（基座一般是用户最终访问的应用）根据路由去加载不同的应用到页面上，即路由分发应用方式
qiankun与single-spa对比
微前端主要需要解决的问题有两个
- 应用加载与切换
-
应用隔离与通信
image.png
qiankun和single-spa对比
activePath与当前的hash对比一致
shadow dom 怎么处理antd 的modal样式问题的
https://cloud.tencent.com/developer/beta/article/2212257
一些组件可能会越过 Shadow Boundary 到外部 Document Tree 插入节点，而这部分节点的样式就会丢失；比如 antd 的 Modal 就会渲染节点至 ducument.body ，引发样式丢失
针对刚才的 antd 场景你可以通过他们提供的 ConfigProvider.getPopupContainer API 来指定在 Shadow Tree 内部的节点为挂载节点，但另外一些其他的组件库，或者你的一些代码也会遇到同样的问题，需要你额外留心。
此外 Shadow DOM 场景下还会有一些额外的事件处理、边界处理等问题
qiankun是怎么做到技术栈无关的
1、通信协议的制定和实现
- 基于浏览器提供的“postMessage”接口实现通用的通信协议，通过该协议，不同的字应用之间可以进行数据传输和通信，实现了子应用的解耦，
- 该协议定义了一些标准的消息格式和字段，从而保证了不同技术栈之间的兼容性和通用性。
- 同时，qiankun 还提供了一些 API，可以方便地进行消息的发送和接收。
2、模块加载器设计和实现
- qiankun 内部使用了一个独立的模块加载器来加载和执行不同的子应用。该加载器可以根据不同的子应用需求，选择合适的技术栈进行加载和执行。
- 加载器还支持动态加载和卸载子应用，从而实现了应用的动态扩展和升级。
- 在加载子应用时，加载器会对子应用的代码进行适当的转换和处理，从而保证了不同技术栈之间的兼容性和互相隔离性。
3、沙箱设计与实现（single spa没有）
- 使用了一个沙箱来隔离不同子应用之间的代码和数据。
- 该沙箱可以在不同技术栈之间进行隔离，并且支持在子应用中使用全局变量和函数。
- 沙箱的实现依赖于一些浏览器提供的安全特性，如 iframe 和 Content Security Policy（CSP），从而保证了应用的安全性。
模块加载器
微前端框架 qiankun 内部使用了一个独立的模块加载器来加载和执行不同的子应用，该加载器实现技术栈无关的特性。具体来说，模块加载器的设计和实现主要包括以下几个方面：
加载子应用的配置：在加载子应用时，模块加载器需要通过一些配置信息来了解子应用的相关信息。这些信息包括子应用的名称、入口 URL、运行时参数等。模块加载器会根据这些配置信息来选择合适的技术栈进行加载和执行。
加载子应用的代码：模块加载器会通过浏览器提供的动态创建 script 标签的方式，加载子应用的代码。在加载代码时，模块加载器会对代码进行适当的转换和处理，以保证不同技术栈之间的兼容性和互相隔离性。例如，在加载 React 应用时，模块加载器会通过 Babel 转译 ES6 代码和 JSX 语法，以保证在不支持这些语法的浏览器中也能够正常运行。
执行子应用的代码：加载器在加载子应用代码后，需要执行该代码来启动子应用。在执行代码时，模块加载器会创建一个独立的运行环境，用来隔离不同子应用之间的代码和数据。该运行环境基于浏览器提供的 iframe 技术，从而实现了代码和数据的互相隔离。同时，该运行环境还支持在子应用中使用全局变量和函数，从而实现了一定的共享性。
动态加载和卸载子应用：模块加载器还支持在运行时动态加载和卸载子应用。在加载子应用时，模块加载器会创建一个独立的 iframe，用来隔离该子应用的代码和数据。在卸载子应用时，模块加载器会销毁该 iframe，并清除该子应用的代码和数据，从而释放内存和资源。
沙箱
在微前端框架 qiankun 中，沙箱是实现子应用之间隔离的核心组件之一，它能够在不同技术栈之间进行隔离，从而确保每个子应用的运行环境都是独立的。沙箱的设计和实现主要包括以下几个方面：
运行环境的隔离：沙箱首先需要在运行环境层面进行隔离，确保每个子应用运行在自己的沙箱中。为此，沙箱会利用浏览器提供的 iframe 技术创建独立的运行环境，从而实现每个子应用的隔离。
代码隔离：沙箱还需要确保每个子应用的代码之间互相隔离，从而防止代码之间的冲突。为此，沙箱会使用 JavaScript 的沙箱技术，通过运行子应用代码的方式来实现隔离。具体来说，沙箱会创建一个 JavaScript 上下文环境，将子应用的代码加载进去，并运行该代码，从而实现代码的隔离。
DOM 隔离：沙箱还需要确保每个子应用之间的 DOM 结构互相隔离，从而防止样式和脚本之间的冲突。为此，沙箱会使用 Shadow DOM 技术，将子应用的 DOM 结构封装在一个 Shadow DOM 中，从而确保 DOM 的隔离。
全局变量隔离：沙箱还需要确保每个子应用之间的全局变量互相隔离，从而防止变量的冲突。为此，沙箱会使用 Proxy 技术，将子应用的全局变量封装在一个 Proxy 中，并拦截该 Proxy 的读写操作，从而实现全局变量的隔离。
通过以上几个方面的设计和实现，沙箱能够在不同技术栈之间进行隔离，从而确保每个子应用的运行环境都是独立的，并且代码、DOM 和全局变量之间不会相互干扰。这为微前端框架 qiankun 的技术栈无关特性提供了坚实的保障。
