在上述示例中，main-app 使用 import() 函数动态加载 shared_module 中的 Button 组件。通过动态加载，可以在需要时异步地加载远程模块，并在加载完成后使用模块。
在微前端应用中可以实现模块共享和动态加载，提供了更好的代码复用和可扩展性。通过模块共享，可以避免重复加载和代码冗余，而动态加载则可以按需加载模块，提高应用的性能和用户体验。
说说qiankun的资源加载机制（import-html-entry）
qiankun import-html-entry是qiankun 框架中用于加载子应用的 HTML 入口文件的工具函数。它提供了一种方便的方式来动态加载和解析子应用的 HTML 入口文件，并返回一个可以加载子应用的 JavaScript 模块。
具体而言，import-html-entry 实现了以下功能：
- 加载 HTML 入口文件：
import-html-entry会通过创建一个<link>标签来加载子应用的 HTML 入口文件。这样可以确保子应用的资源得到正确加载，并在加载完成后进行处理。 - 解析 HTML 入口文件：一旦 HTML 入口文件加载完成，
import-html-entry将解析该文件的内容，提取出子应用的 JavaScript 和 CSS 资源的 URL。 - 动态加载 JavaScript 和 CSS 资源：
import-html-entry使用动态创建<script>和<link>标签的方式，按照正确的顺序加载子应用的 JavaScript 和 CSS 资源。 - 创建沙箱环境：在加载子应用的 JavaScript 资源时，
import-html-entry会创建一个沙箱环境（sandbox），用于隔离子应用的全局变量和运行环境，防止子应用之间的冲突和污染。 - 返回子应用的入口模块：最后，
import-html-entry返回一个可以加载子应用的 JavaScript 模块。这个模块通常是一个包含子应用初始化代码的函数，可以在主应用中调用以加载和启动子应用。
通过使用 qiankun import-html-entry，开发者可以方便地将子应用的 HTM
说说qiankun的资源加载机制（import-html-entry）
qiankun import-html-entry是qiankun 框架中用于加载子应用的 HTML 入口文件的工具函数。它提供了一种方便的方式来动态加载和解析子应用的 HTML 入口文件，并返回一个可以加载子应用的 JavaScript 模块。
具体而言，import-html-entry 实现了以下功能：
- 加载 HTML 入口文件：
import-html-entry会通过创建一个<link>标签来加载子应用的 HTML 入口文件。这样可以确保子应用的资源得到正确加载，并在加载完成后进行处理。 - 解析 HTML 入口文件：一旦 HTML 入口文件加载完成，
import-html-entry将解析该文件的内容，提取出子应用的 JavaScript 和 CSS 资源的 URL。 - 动态加载 JavaScript 和 CSS 资源：
import-html-entry使用动态创建<script>和<link>标签的方式，按照正确的顺序加载子应用的 JavaScript 和 CSS 资源。 - 创建沙箱环境：在加载子应用的 JavaScript 资源时，
import-html-entry会创建一个沙箱环境（sandbox），用于隔离子应用的全局变量和运行环境，防止子应用之间的冲突和污染。 - 返回子应用的入口模块：最后，
import-html-entry返回一个可以加载子应用的 JavaScript 模块。这个模块通常是一个包含子应用初始化代码的函数，可以在主应用中调用以加载和启动子应用。
通过使用 qiankun import-html-entry，开发者可以方便地将子应用的 HTML 入口文件作为模块加载，并获得一个可以加载和启动子应用的函数，简化了子应用的加载和集成过程。
说说现有的几种微前端框架，它们的优缺点？
以下是对各个微前端框架优缺点的总结：
- qiankun 方案优点
- 降低了应用改造的成本，通过html entry的方式引入子应用；
- 提供了完备的沙箱方案，包括js沙箱和css沙箱；
- 支持静态资源预加载能力。
- 缺点
- 适配成本较高，包括工程化、生命周期、静态资源路径、路由等方面的适配；
- css沙箱的严格隔离可能引发问题，js沙箱在某些场景下执行性能下降；
- 无法同时激活多个子应用，不支持子应用保活；
- 不支持vite等esmodule脚本运行。
- micro-app 方案优点
- 使用 webcomponent 加载子应用，更优雅；
- 复用经过大量项目验证过的 qiankun 沙箱机制，提高了框架的可靠性；
- 支持子应用保活；
- 降低了子应用改造的成本，提供了静态资源预加载能力。
- 缺点
- 接入成本虽然降低，但路由依然存在依赖；
- 多应用激活后无法保持各子应用的路由状态，刷新后全部丢失；
- css 沙箱无法完全隔离，js 沙箱做全局变量查找缓存，性能有所优化；
- 支持 vite 运行，但必须使用 plugin 改造子应用，且 js 代码没办法做沙箱隔离；
- 对于不支持 webcomponent 的浏览器没有做降级处理。
- EMP 方案优点
- webpack 联邦编译可以保证所有子应用依赖解耦；
- 支持应用间去中心化的调用、共享模块；
- 支持模块远程 ts 支持。
- 缺点
- 对 webpack 强依赖，对于老旧项目不友好；
- 没有有效的 css 沙箱和 js 沙箱，需要靠用户自觉；
- 子应用保活、多应用激活无法实现；
- 主、子应用的路由可能发生冲突。
- 无界方案优点
- 基于 webcomponent 容器和 iframe 沙箱，充分解决了适配成本、样式隔离、运行性能、页面白屏、子应用通信、子应用保活、多应用激活、vite框架支持、应用共享等问题。
- 缺点
- 在继承了iframe优点的同时，缺点依旧还是存在
