当前位置：首页 > article >正文

微前端应用+MicApp、无界、乾坤、EMP+简要了解+部分场景应用

article 2024/12/25 16:31:32

文章目录

- 微前端框架简要介绍
- MicApp、无界、乾坤、EMP 技术应用对比
- 实例场景应用
- 技术细节
- 小结（微前端框架应用关键）

微前端框架简要介绍

MicApp
- 概述：
  - MicApp是一种微前端解决方案，它专注于提供高效的微应用管理和集成方式。其设计理念是让每个微应用能够在相对独立的环境中开发和运行，同时又能方便地与其他微应用进行交互和组合。
- 技术特点：
  - 隔离性较好：类似于其他微前端框架，MicApp强调对微应用的隔离。它通过一定的技术手段（如沙箱机制）来防止微应用之间的样式和脚本相互干扰。例如，在处理JavaScript变量和函数时，它会为每个微应用创建独立的执行环境，避免全局变量污染。
  - 灵活的通信机制：MicApp提供了多种微应用之间的通信方式。可以通过自定义事件或者基于消息队列的方式来实现微应用之间的数据传递和交互。比如，一个微应用可以发布一个“用户登录成功”的事件，其他感兴趣的微应用可以订阅这个事件并做出相应的响应，如更新自身的用户状态显示。
  - 易于集成：它能够方便地集成到现有的前端项目中，无论是基于Vue.js、React.js还是其他框架构建的项目。在集成过程中，只需要按照其提供的API进行简单的配置，就可以将微应用加载到主应用中。例如，在一个已经有大量业务逻辑的React应用中，开发人员可以轻松地使用MicApp将新开发的微应用集成进来，而不需要对原有的React应用进行大规模的改造。
- 应用场景：
  - 多模块系统：适用于具有多个功能模块的企业级应用。例如，一个企业资源规划（ERP）系统，包含财务模块、人力资源模块、生产管理模块等，这些模块可以分别作为微应用通过MicApp进行集成，每个模块的开发团队可以独立工作，提高开发效率。
  - 渐进式重构：对于那些希望从单体前端应用逐步过渡到微前端架构的项目，MicApp提供了一种可行的方案。可以先将部分功能抽取成微应用进行独立开发和部署，然后逐步替换原单体应用中的对应功能。
无界（Wujie）
- 概述：
  - 无界是一个跨框架的微前端解决方案，其核心目标是打破不同技术框架之间的壁垒，实现微应用在不同框架下的无缝集成。它能够让使用Vue.js、React.js、Angular等不同框架的微应用在同一个主应用中和谐共处。
- 技术特点：
  - 框架无关性：这是无界的一个显著特点。它通过一些适配和转换机制，使得不同框架的微应用能够在统一的运行环境中工作。例如，当一个React微应用和一个Vue微应用需要在同一个页面展示时，无界会处理好它们之间的差异，包括生命周期管理、组件渲染等方面的不同。
  - 高性能渲染：采用了高效的渲染策略，能够快速地将微应用加载并渲染到主应用中。它利用了现代浏览器的一些特性，如动态加载脚本、异步渲染等技术，减少用户等待时间。例如，在加载一个大型微应用时，无界可以根据用户的网络情况和设备性能，分阶段加载和渲染微应用的不同部分，优先展示关键内容。
  - 完善的通信协议：为微应用之间的通信建立了一套完善的协议。这种通信协议不仅支持简单的数据传递，还能够处理复杂的交互场景，如微应用之间的方法调用和状态共享。比如，在一个包含多个微应用的电商系统中，商品微应用和购物车微应用可以通过无界的通信协议实时更新彼此的数据，如商品数量变化、价格更新等。
- 应用场景：
  - 技术栈异构的项目：在一个团队或企业内部，由于历史原因或者不同项目的需求，可能会存在多种前端技术栈。无界可以用于将这些不同技术栈的应用整合在一起。例如，一个公司收购了另一个公司，两个公司的前端系统分别基于不同的框架构建，通过无界可以将它们整合到一个统一的平台上。
  - 插件式系统开发：可以用于开发插件式的前端系统，不同的插件可以作为微应用，用不同的框架开发，然后通过无界集成到主应用中。就像浏览器插件一样，用户可以根据自己的需求选择安装和使用不同的插件（微应用），而这些插件可以基于自己的技术优势提供不同的功能。
乾坤（Qiankun）
- 概述：
  - 乾坤是蚂蚁金服开源的一款微前端框架，它具有强大的微应用管理和加载能力，能够很好地支持企业级复杂应用的微前端架构改造。
- 技术特点：
  - 沙箱机制成熟：乾坤的沙箱机制比较成熟，能够有效地隔离微应用的JavaScript环境。它通过代理（Proxy）等技术手段，对微应用访问全局对象（如window）进行严格控制，防止一个微应用的脚本对其他微应用或者主应用造成影响。例如，当一个微应用尝试修改全局变量时，乾坤的沙箱会拦截并处理这个操作，确保每个微应用都在自己独立的“沙箱”中运行。
  - 动态加载与卸载：支持微应用的动态加载和卸载。这意味着可以根据用户的操作或者业务需求，实时地将微应用加载到主应用中或者从主应用中移除。比如，在一个包含多个功能模块的金融应用中，当用户进入某个特定业务场景时，乾坤可以快速加载相关的微应用，当用户离开这个场景时，又可以及时卸载该微应用，以节省资源。
  - 样式隔离与共享：在处理微应用的样式方面，乾坤提供了样式隔离的功能，同时也支持有条件的样式共享。它通过一些CSS加载和处理技巧，如给每个微应用的样式添加独立的作用域，防止样式冲突。但在需要的时候，也可以通过配置让某些样式在微应用之间共享，比如共享主题样式。
- 应用场景：
  - 大型金融应用：在金融行业的复杂应用场景中，如网上银行、金融交易平台等，乾坤可以将众多的功能模块（如账户查询、转账汇款、理财推荐等）划分为微应用进行独立开发和管理。这些微应用可以由不同的团队负责，并且能够在乾坤的框架下高效地集成和运行。
  - 微服务前端架构落地：对于采用微服务架构的企业，乾坤可以作为前端微服务的实现工具，将与各个微服务对应的前端微应用进行整合。例如，一个电商企业的后端采用微服务架构，包括订单服务、商品服务、用户服务等，乾坤可以将与这些后端微服务对应的前端微应用整合在一起，构建一个完整的电商前端平台。
EMP
1. EMP（Element Micro - Frontend Platform）概述
  - EMP是一种微前端解决方案，它重点关注基于Web Components的微前端架构实现。其理念是利用Web Components的特性，如自定义元素、影子DOM和HTML模板，来构建和集成微应用。通过将微应用封装为Web Components，EMP提供了一种相对独立、可复用的微应用开发和集成方式。
2. 技术特点
  - 基于Web Components的封装
    - EMP利用Web Components技术将微应用封装为独立的组件单元。例如，开发人员可以使用自定义元素来定义微应用的入口点，通过影子DOM来隔离微应用的样式和DOM结构。这样每个微应用就像一个独立的“黑盒”，可以方便地在不同的主应用中进行复用。以一个简单的用户登录微应用为例，它可以被封装为一个自定义元素，如<login - microapp>，其内部的HTML结构、样式和交互逻辑都被隐藏在这个自定义元素内部，通过影子DOM进行隔离。
  - 良好的样式隔离与复用
    - 由于采用了Web Components的影子DOM，EMP在样式隔离方面表现出色。每个微应用的样式都被限制在自己的影子DOM范围内，不会与其他微应用或主应用的样式相互干扰。同时，它也支持有条件的样式复用。例如，在一个主题风格统一的系统中，可以通过一定的配置，使微应用能够复用主应用的主题样式，同时保持自身样式的独立性，在需要修改主题时，只需要更新主应用的主题样式，微应用会自动适配。
  - 简单的通信机制
    - EMP提供了相对简单直接的微应用通信机制。它可以通过自定义事件在微应用和主应用之间，以及微应用之间进行通信。例如，一个微应用可以在用户完成某个操作（如提交表单）后，触发一个自定义事件，主应用或其他微应用可以监听这个事件并做出相应的响应。这种通信机制相对容易理解和实现，降低了开发人员在微应用通信方面的技术难度。

MicApp、无界、乾坤、EMP 技术应用对比

技术难度对比
- MicApp
  - 优点：
    - 相对容易上手。它提供了比较直观的API用于微应用的加载和集成，对于有一定前端开发经验的团队来说，理解和使用其基本功能不会过于复杂。例如，在微应用的通信机制方面，其自定义事件的方式比较符合常规的开发思维。
    - 隔离机制实现相对简洁。在处理微应用之间的隔离时，采用的沙箱等技术在概念上比较容易理解，不需要深入了解复杂的浏览器底层机制或高级的JavaScript特性。
  - 缺点：
    - 功能丰富度相对有限。与一些成熟的微前端框架相比，在处理复杂的跨框架集成和高性能优化方面可能略显不足。例如，在面对不同框架微应用的深度交互场景时，可能需要开发团队自己编写更多的适配代码。
- 无界（Wujie）
  - 优点：
    - 跨框架能力强，技术难度主要体现在对不同框架的兼容和整合上。对于熟悉多种前端框架的开发团队来说，无界的框架无关性是其优势，但这也要求团队对不同框架的原理和特性有深入的理解。例如，要正确处理Vue.js和React.js微应用的生命周期和组件通信，需要开发者掌握这两个框架的底层知识。
    - 高性能渲染涉及到一些浏览器高级特性的运用。虽然这使得它在性能方面表现出色，但也要求开发人员具备一定的浏览器工作原理和性能优化知识，如动态加载脚本的最佳实践、异步渲染的实现细节等。
  - 缺点：
    - 技术复杂度较高。由于要解决跨框架整合这个复杂的问题，其内部实现机制相对复杂，开发人员需要花费更多的时间来学习和掌握其原理。例如，在调试不同框架微应用之间的交互问题时，可能会因为其复杂的适配和转换机制而增加难度。
- 乾坤（Qiankun）
  - 优点：
    - 沙箱机制成熟，提供了较好的隔离效果。然而，要充分理解和利用其沙箱机制，需要对JavaScript的代理（Proxy）等高级特性有一定的了解。例如，开发人员需要知道如何通过代理来拦截微应用对全局对象的访问，以避免潜在的冲突。
    - 动态加载和卸载功能强大。实现这一功能涉及到对应用状态管理和资源分配的精细控制，开发人员需要掌握相关的知识，如如何正确地处理微应用加载和卸载过程中的事件和数据传递。
  - 缺点：
    - 对于初学者来说，学习曲线较陡。其丰富的功能和复杂的内部机制，如样式隔离和共享的实现方式，需要开发人员投入更多的时间来学习和实践，才能熟练运用。
- EMP
  - 优点：
    - 基于Web Components的实现方式使得其技术概念相对清晰。对于熟悉Web Components标准的开发人员来说，EMP比较容易上手。其封装和隔离机制遵循Web Components的规范，不需要深入学习复杂的沙箱或跨框架整合技术。例如，在创建和使用微应用时，只要理解了自定义元素和影子DOM的基本概念，就可以快速进行开发。
    - 样式隔离和通信机制相对简单，降低了开发的复杂性。开发人员不需要花费大量时间来处理复杂的样式冲突问题和设计复杂的通信协议。这使得在开发微应用时，可以更专注于业务逻辑本身。
  - 缺点：
    - 功能可能相对较少。与一些功能丰富的微前端框架（如乾坤）相比，EMP可能在动态加载卸载微应用、处理复杂的跨框架集成等方面的功能不够强大。例如，在需要快速动态加载多个微应用以响应用户操作的场景中，EMP可能需要开发人员自己编写更多的逻辑来实现。
    - 对Web Components的兼容性依赖较高。如果浏览器对Web Components的支持存在问题，可能会影响EMP微应用的运行。虽然现代主流浏览器对Web Components有较好的支持，但在一些旧版本浏览器或特定环境下，可能需要进行额外的兼容性处理。
老项目改造的成本对比
- MicApp
  - 优点：
    - 易于集成到现有项目。如果老项目是基于常见的前端框架构建的，如Vue.js或React.js，MicApp可以相对轻松地被引入。它对原项目的结构和代码风格的改动要求相对较小，只需要按照其API进行简单的配置就可以开始将功能模块逐步改造为微应用。例如，对于一个基于Vue.js的老项目，开发人员可以先将部分组件封装为微应用，通过MicApp加载到主应用中，在这个过程中，基本不需要对原Vue.js组件的内部逻辑进行大规模修改。
    - 改造过程相对渐进。可以采用小步快跑的方式，先对一些边缘功能或者独立的模块进行微应用化改造，然后逐步扩展到核心功能。这样可以在不影响老项目正常运行的情况下，逐步实现微前端架构的改造。
  - 缺点：
    - 可能需要额外的工作来处理复杂的业务逻辑迁移。如果老项目的业务逻辑比较复杂，且模块之间的耦合度较高，在将模块改造为微应用时，可能需要花费更多的精力来解耦和重新组织业务逻辑，以适应微应用的独立开发和运行模式。
- 无界（Wujie）
  - 优点：
    - 适合技术栈异构的老项目改造。如果老项目是由不同技术框架构建的多个子系统组成，无界可以发挥其跨框架整合的优势。例如，一个老项目包含了基于Vue.js的前端展示模块和基于React.js的管理模块，无界可以将它们整合在一起，作为微应用进行统一管理，减少因为技术栈差异导致的改造困难。
    - 插件式的集成理念有助于逐步改造。可以将老项目中的各个功能模块看作是插件（微应用），通过无界的方式逐步将它们进行改造和集成。这种方式可以在一定程度上保持老项目的原有架构，同时实现向微前端的过渡。
  - 缺点：
    - 前期调研和适配成本较高。由于其技术复杂度和跨框架的特点，在改造老项目之前，需要对老项目的技术栈、模块交互方式等进行详细的调研，以确定如何正确地使用无界进行整合。而且在改造过程中，可能需要对不同框架的微应用进行较多的适配工作，以确保它们能够在无界的框架下正常运行。
- 乾坤（Qiankun）
  - 优点：
    - 对于大型老项目有较好的适用性。如果老项目是大型的企业级应用，乾坤的成熟功能，如沙箱机制、动态加载卸载等，可以有效地帮助将老项目改造为微前端架构。例如，在一个大型金融老项目中，将众多的功能模块改造为微应用后，乾坤可以很好地管理这些微应用之间的隔离、通信和资源分配。
    - 提供了比较全面的改造方案。包括从微应用的划分、加载方式到样式处理等一系列的解决方案，减少了改造过程中的不确定性。开发人员可以参考其文档和最佳实践，对老项目进行系统的改造。
  - 缺点：
    - 改造过程可能会对老项目的结构产生较大的冲击。由于乾坤的功能较为强大，在改造过程中可能需要对老项目的整体架构、模块划分和代码组织方式进行较大的调整。例如，为了实现有效的沙箱隔离和动态加载，可能需要重新设计模块之间的接口和通信方式，这可能会增加改造的工作量和风险。
- EMP
  - 优点：
    - 对原项目结构的影响相对较小。如果老项目已经在一定程度上采用了组件化的开发方式，将其改造为EMP微前端架构会比较容易。因为EMP基于Web Components的封装方式与组件化开发理念相契合，只需要将原有的组件或功能模块逐步封装为Web Components形式的微应用即可。例如，对于一个基于Vue.js或React.js的老项目，开发人员可以将部分组件提取出来，按照EMP的要求封装为微应用，而不需要对原项目的框架和核心业务逻辑进行大规模的改造。
    - 改造过程相对灵活。可以根据老项目的实际情况，逐步将功能模块改造为微应用。由于其简单的通信机制和良好的样式隔离，在改造过程中，不会因为微应用之间的复杂交互和样式冲突问题而增加过多的成本。例如，在一个包含多个功能模块的老项目中，可以先选择一个相对独立的模块进行微应用改造，测试通过后，再逐步扩展到其他模块。
  - 缺点：
    - 如果老项目没有组件化基础，可能需要先进行组件化改造。对于一些传统的单体前端项目，在采用EMP进行微前端改造之前，可能需要花费时间将其代码进行组件化重构，这会增加一定的改造成本。例如，将一个大量使用全局变量和内联样式的老项目改造为适合EMP的微应用架构，需要先将代码进行整理，提取出独立的组件，然后才能进行微应用的封装。
    - 对于非Web Components技术栈的老项目，可能需要更多的适配工作。如果老项目是基于一些特定的前端框架，且与Web Components的集成不够友好，在改造过程中可能需要编写更多的适配代码来确保微应用能够正常运行。例如，在一个基于AngularJS（较老版本）的项目中，将其改造为EMP微前端架构可能需要处理AngularJS与Web Components之间的兼容性问题，如数据绑定和生命周期的协调。

实例场景应用

企业级管理系统：
- 场景：在一个大型企业中，存在多个不同业务部门的管理系统，如人力资源管理系统、财务管理系统、项目管理系统等。这些系统可能使用不同的技术栈开发，但都需要集成到一个统一的企业门户中，以便员工能够方便地访问和使用。
- 实现方式：企业门户作为主应用，使用无界微前端框架来加载和集成各个子应用。例如，人力资源管理系统使用 Vue.js 开发，财务管理系统使用 React.js 开发，项目管理系统使用 Angular 开发。通过无界的能力，将这些不同技术栈的子应用封装成独立的模块，并在主应用中进行动态加载和渲染。这样，员工在访问企业门户时，可以根据自己的需求快速切换到不同的管理系统，同时各个子应用之间的样式和数据也能够得到有效的隔离。

技术细节

多个系统集成，主系统登录同步子系统登录设置

基于单点登录（SSO）的解决方案
- 原理：
  - 单点登录是一种在多个相关但独立的系统中实现用户身份认证的技术。在多个系统集成的场景下，通过一个统一的身份认证中心（IdP）来管理用户的登录凭证。当用户在主系统登录成功后，主系统会从身份认证中心获取一个包含用户身份信息的令牌（如JWT - JSON Web Token），然后将这个令牌传递给需要同步登录的子系统。子系统收到令牌后，会向身份认证中心验证令牌的有效性，若有效则认为用户已经登录。
- 实现步骤示例：
  - 配置身份认证中心：首先需要建立一个独立的身份认证中心，如使用开源的Keycloak或者自行开发一个基于OAuth 2.0或OpenID Connect协议的认证服务。这个认证中心负责存储用户的账号密码等登录信息，并能够生成和验证身份令牌。
  - 主系统集成：主系统的登录模块在用户成功登录后，通过认证中心提供的接口获取令牌。例如，在一个基于Spring Boot的主系统中，可以使用相关的OAuth客户端库来与认证中心进行交互。假设认证中心的登录接口返回一个JWT令牌，主系统将这个令牌存储在本地（如浏览器的本地存储），以便后续传递给子系统。
  - 子系统集成：子系统需要配置认证中心的验证端点。当主系统将令牌传递给子系统时（可以通过URL参数、请求头或者自定义的通信机制），子系统使用认证中心提供的验证库来验证令牌的真实性和有效性。例如，一个基于React.js的子系统可以在页面加载时检查是否接收到有效的令牌，如果有则自动登录用户，跳过自己的登录流程。
通过共享Cookie或存储（Local Storage/Session Storage）来同步
- 原理：
  - 如果主系统和子系统在相同的域名（或存在信任关系的子域名）下，它们可以共享Cookie。当用户在主系统登录后，主系统可以在Cookie中设置用户登录的标识信息。子系统在加载时检查这个Cookie，如果存在登录标识，则认为用户已经登录。另外，也可以使用浏览器的本地存储（Local Storage）或会话存储（Session Storage）来传递登录信息，不过这种方式相对Cookie安全性稍低，因为本地存储的数据可以被JavaScript代码访问。
- 实现步骤示例：
  - Cookie方式（同域名情况）：主系统在用户登录成功后，通过服务器端代码（如在Java的Servlet中使用HttpServletResponse对象）设置一个带有用户登录标识的Cookie，例如userLoggedIn=true。子系统的服务器端代码（如在Node.js的Express框架中）在收到请求时，检查这个Cookie是否存在以及其值是否为true，如果是则自动登录用户。
  - 本地存储/会话存储方式：主系统在用户登录成功后，使用JavaScript将用户登录信息（如用户ID、用户名等）存储到本地存储或会话存储中。例如，在一个Vue.js主系统中，可以使用localStorage.setItem('userID', userId)。子系统在加载页面时，通过JavaScript读取这个存储的值。例如，一个基于React.js的子系统可以在componentDidMount生命周期函数中检查localStorage.getItem('userID')是否存在，如果存在则使用这个值来自动登录用户。不过，这种方式需要注意跨域访问存储的问题，如果主系统和子系统处于不同的域，可能需要配置跨域资源共享（CORS）来允许子系统访问主系统设置的存储信息。
利用微前端框架的通信机制来同步登录状态
- 原理：
  - 许多微前端框架（如无界、乾坤等）提供了微应用之间的通信功能。在主系统和子系统作为微应用集成的场景下，可以利用这种通信机制来传递登录状态。当主系统登录成功后，通过微前端框架的通信渠道（如发布 - 订阅模式）发送一个登录成功的消息，包含用户的身份信息。子系统订阅了这个消息，在收到消息后，根据其中的用户身份信息进行登录操作。
- 实现步骤示例：
  - 以无界为例：在无界框架中，主系统在登录成功后，利用无界提供的事件发布机制（如window.dispatchEvent）发布一个userLoggedIn事件，事件对象中包含用户的登录信息（如用户名、用户ID等）。子系统在初始化时，通过无界的事件监听机制（如window.addEventListener）监听这个userLoggedIn事件。当收到事件后，子系统从事件对象中获取用户登录信息，并调用自己的登录接口（可能是一个内部的API或者与后端服务交互的接口）来完成登录操作，使得用户在子系统中也处于登录状态。

主系统在监听子系统处于load 阶段时传值给子系统时，子系统处于加载页面的哪个阶段，以vue3 为例

微前端框架初始化阶段

无界微前端框架示例：
- 无界框架在加载子系统时，也有类似的初始化过程。当子系统开始加载，会触发一些初始化的钩子函数。如果主系统在子系统加载初期传递值，例如通过URL参数传递，子系统可以在初始化的函数中（如mount函数）解析URL参数来获取主系统传递的值。

// 子系统的mount函数（假设是基于无界框架的JavaScript模块）
function mount(props) {
    const urlParams = new URLSearchParams(window.location.search);
    const valueFromMain = urlParams.get('valueFromMain');
    console.log('在mount阶段通过URL参数接收到主系统传递的值:', valueFromMain);
    // 根据接收到的值进行后续操作，如更新DOM等
}

页面渲染前阶段（生命周期中的beforeMount或类似阶段）

对于基于Vue.js的子系统：
- 在Vue.js中，子系统有beforeMount生命周期阶段。如果主系统在这个阶段之前传递值，子系统可以在beforeMount阶段获取并处理这些值。例如，主系统通过微前端框架的通信机制传递一个用户信息对象，子系统在beforeMount阶段接收这个对象，并可以将其存储到组件的数据属性中，用于后续的渲染。

// Vue.js子系统组件
export default {
    data() {
        return {
            userInfoFromMain: null
        };
    },
    beforeMount() {
        // 假设通过某种微前端通信方式接收主系统传递的用户信息
        const userInfo = this.$root.$emit('userInfoFromMain');
        if (userInfo) {
            this.userInfoFromMain = userInfo;
        }
    },
    // 后续可以在模板中使用userInfoFromMain进行渲染
    template: '<div>用户姓名: {{userInfoFromMain.name}}</div>'
};

页面渲染阶段（生命周期中的mounted或类似阶段）

以Vue.js为例：
- 在mounted阶段，子系统的DOM已经渲染完成。如果主系统在这个阶段传递值，子系统可以通过更新组件的响应式数据来实现界面的更新。例如，主系统传递一个新的配置参数，子系统在mounted阶段接收后，可以通过修改数据属性，触发Vue.js的响应式更新机制，从而更新页面。

export default {
    data() {
        return {
            configValueFromMain: null
        };
    },
    mounted() {
        // 假设通过微前端通信通道接收主系统传递的配置值
        const configValue = this.$root.$emit('configValueFromMain');
        if (configValue) {
            this.configValueFromMain = configValue;
        }
    },
    template: '<div>配置值: {{configValueFromMain}}</div>'
};

iframe load 函数加载回调对应子应用生命周期分析
1. iframe的load函数与子应用生命周期关系概述
  - 当iframe的load函数返回时，对于子应用（以Vue 3为例），通常意味着子应用的HTML文档已经加载完成，这个阶段大致对应于Vue 3组件生命周期中的beforeMount阶段之前，但具体情况还会受到子应用自身初始化逻辑的影响。
2. 详细分析
  - HTML加载完成但未开始渲染（类似beforeCreate阶段）
    - 在iframe的load函数返回时，iframe内部的HTML文档已经加载进浏览器内存，对于子应用而言，这类似于Vue 3组件生命周期中的beforeCreate阶段。此时，子应用的Vue实例尚未创建，组件的选项（如data、methods等）还没有进行处理。
    - 例如，如果子应用是一个Vue 3组件，在这个阶段，组件相关的JavaScript代码可能还没有开始执行，只是HTML结构已经准备好。这就好比搭建好了舞台，但演员（JavaScript逻辑和组件实例）还没开始上场。
  - 即将开始挂载（类似beforeMount阶段）
    - 稍晚于beforeCreate阶段，当iframe加载完成后，子应用很快就会进入到挂载阶段。这个阶段类似于Vue 3的beforeMount阶段，此时子应用的组件实例即将被挂载到iframe内部的DOM节点上，但还没有真正开始渲染到页面。
    - 以一个简单的Vue 3子应用为例，在beforeMount阶段，组件的模板（template）已经被编译成渲染函数，但DOM元素还没有被更新。在iframe的load环境下，子应用正处于这个即将进行挂载操作的关键节点。
3. 与实际开发的关联
  - 初始化操作的时机
    - 了解这个阶段对于在子应用中进行正确的初始化操作非常重要。如果需要在子应用中进行一些基于HTML结构的初始化，比如获取iframe内部文档中的某些元素（例如查找特定的id或class的DOM节点），那么在iframe的load函数返回后就可以进行这些操作。
    - 例如，在iframe加载完成后，可以在子应用中通过document.getElementById（假设是在iframe内部的文档环境下）来查找元素，并进行一些数据绑定的初始化工作，这类似于在Vue 3的beforeMount阶段进行的DOM相关操作。
  - 数据传递和通信的影响
    - 对于主应用和子应用之间的数据传递和通信，iframe的load返回这个时间点也很关键。主应用如果要向子应用传递数据，此时子应用已经可以接收这些数据，并在后续的挂载阶段（如mounted阶段）使用这些数据来更新界面或者进行其他逻辑操作。
    - 例如，主应用可以通过iframe的contentWindow属性（在同源策略允许的情况下）向子应用传递一些配置参数，子应用在iframe加载返回后的阶段可以获取这些参数，并在mounted阶段根据参数来渲染不同的内容。

小结（微前端框架应用关键）

微应用的划分与独立性
- 合理划分微应用：
  - 关键在于根据业务功能进行划分。例如，在一个电商平台中，可将商品展示、购物车管理、用户订单处理、支付等功能划分为独立的微应用。这样划分的好处是每个微应用职责明确，便于独立开发和维护。
  - 同时要考虑功能的耦合度。尽量使每个微应用内部的功能高度内聚，与其他微应用的耦合度较低。比如，商品展示微应用主要关注商品信息的展示和搜索，其内部逻辑紧密围绕这个核心功能，而与支付流程的耦合仅通过定义好的接口进行交互。
- 确保微应用独立性：
  - 在技术栈选择上，微应用应能独立选择适合自身功能和团队技术栈的技术。比如，一个对性能要求极高的微应用可能选择原生JavaScript或轻量级框架如Svelte，而一个需要复杂交互和状态管理的微应用可以选择React或Vue。
  - 每个微应用要有独立的开发、测试和部署流程。开发团队可以按照自己的节奏进行开发，使用独立的测试套件进行功能和性能测试，并且能够在不影响其他微应用的情况下进行部署。例如，商品展示微应用的开发团队可以在完成新功能开发和测试后，直接将其部署到生产环境，只要接口和交互规范不变，不会对购物车等其他微应用产生影响。
微应用之间的通信机制
- 选择合适的通信方式：
  - 基于事件的通信是一种常用方式。例如，在一个包含多个微应用的系统中，当用户在一个微应用中完成登录操作后，可以发布一个“user - logged - in”的事件。其他微应用可以订阅这个事件，从而获取用户登录状态并进行相应的更新。
  - 共享状态管理也是一种有效方法。可以使用类似Redux或Vuex的状态管理库，将一些全局状态（如用户信息、主题设置等）存储在一个公共的存储中。各个微应用可以访问和修改这些共享状态，实现数据的同步和交互。
- 通信的安全性和可靠性：
  - 要防止数据泄露和非法访问。在通信过程中，对敏感数据（如用户密码、支付信息等）进行加密处理。例如，当用户登录信息在微应用之间传递时，使用安全的加密算法（如AES）进行加密，并且在接收端进行解密。
  - 确保通信的稳定性。在网络不稳定或微应用加载异常的情况下，要有相应的机制来保证通信的恢复和数据的一致性。比如，当一个微应用因为网络问题暂时无法接收事件时，应该有消息队列等机制来缓存事件，待网络恢复后再进行处理。
主应用的集成与管理功能
- 微应用的加载与卸载：
  - 主应用需要具备动态加载微应用的能力。根据用户的操作或业务场景，在合适的时机加载微应用。例如，在一个企业级应用中，当用户点击“财务报表”按钮时，主应用能够快速加载负责财务报表展示的微应用。
  - 同样，也要支持微应用的卸载。当微应用不再需要时，能够释放其占用的资源。比如，当用户从一个功能模块离开后，主应用可以卸载对应的微应用，以减少内存占用和提高性能。
- 微应用的生命周期管理：
  - 主应用要能够控制微应用的生命周期。包括在微应用加载前的准备工作（如检查资源是否可用、加载必要的配置等），加载过程中的状态监控（如显示加载进度条），以及微应用卸载后的清理工作（如清除缓存、释放事件监听等）。
  - 例如，在微应用加载前，主应用可以通过预加载一些关键资源（如JavaScript脚本和CSS样式表）来提高加载速度；在微应用卸载后，主应用可以触发微应用内部的清理函数，确保没有残留的资源占用。
样式隔离与整合
- 样式隔离技术：
  - 采用CSS Modules或Scoped CSS等技术实现样式隔离。CSS Modules会将CSS类名进行哈希处理，使得每个微应用的样式类名具有唯一性，避免样式冲突。Scoped CSS则通过在HTML标签上添加唯一的属性来限制CSS的作用范围。
  - 例如，在一个使用Vue的微应用中，使用Scoped CSS时，每个组件的样式会自动添加一个唯一的data - v - [hash]属性，确保样式只作用于该组件内部，不会影响其他微应用的样式。
- 样式整合与主题统一：
  - 当需要统一系统的主题风格时，要有一种机制来共享和整合样式。可以通过定义全局的主题变量（如颜色、字体等），让各个微应用引用这些变量来保持风格一致。
  - 例如，在一个企业管理系统中，主应用可以定义主题颜色变量（如-- primary - color: #007bff;），各个微应用在编写样式时可以使用这个变量来设置按钮、标题等元素的颜色，从而实现整个系统主题的统一。