微前端的主流实践及相关问题

感觉用这个的原因 一般有这些
组里没有好活卷晋升了 需要整点技术需求 刚好组里又有一堆老史山项目但是有不能不用 这个时候可以考虑用

感觉这个都是前两年进行改造的比较多 现在实际工作中可能会参与的是治理之类的工作吧

简单说为什么要用 就是你的系统中 有一部分是别人的页面（业务方）你没法完整控制系统中所有组件 就比如说一个基座应用 具体的业务团队要往你中间各种塞内容这样的

缺点：系统复杂度肯定是增加的 然后就是性能问题 兼容问题的 包变大呀 有些库会和qiankun之类的库会产生冲突和bug 就是会有额外的开发成本 就需要你去考量他是不是真的有必要了

什么是微前端？
简而言之，微前端（Micro Frontends）是一种将单一的前端应用拆分成多个独立的小应用的架构风格。每个小应用可以独立开发、测试、部署，而对于最终用户来说，这些小应用在视觉和交互上依然是一个统一的产品。
实现微前端的方式有很多种，目前主流的微前端框架主要有以下几种：
iframe技术： 早期的微前端方案大多采用iframe来嵌套不同的应用，简单易用，但在跨域通信、样式隔离、性能等方面有较大的局限性。
无界框架（Wujie）： 腾讯出品的无界框架在iframe的基础上，进行了优化，使用了Shadow DOM和Proxy技术来解决样式隔离和JS沙箱问题，弥补了iframe的一些缺陷。
Qiankun： 基于single-spa实现的微前端框架，是目前最成熟的微前端解决方案之一。它支持多种框架和技术栈的组合，提供了完善的生命周期管理、资源预加载、主子应用通信等功能，非常适合生产环境中的使用。
Module Federation（模块联邦）： 这是Webpack5引入的一项新特性，它允许多个独立的构建项目共享模块，从而实现跨应用的模块共享。与传统的微前端框架不同，Module Federation更注重模块级别的共享和重用。
微前端的设计思想
微前端并不仅仅是技术的叠加，它背后有深刻的设计理念支持：
技术不可知主义： 每个团队可以选择最适合自己需求的技术栈，而不需要担心与其他团队的技术栈冲突。这种灵活性是微前端架构的一个重要特点。
团队之间的代码隔离： 微前端要求各团队的代码能够完全独立，避免共享同一运行时环境和全局变量。这样可以避免团队间的代码依赖和耦合问题。
独立开发与部署： 微前端的粒度不一定要求是整个应用级别的，甚至可以是页面级别，或是更小的组件级别，保证每个部分都能独立迭代和更新。
适合使用微前端的场景
并不是所有的项目都适合采用微前端架构，适合微前端的场景通常具有以下特点：
大型项目或平台： 如果项目非常庞大，团队数量多，功能复杂且需要频繁更新，微前端可以帮助将复杂的应用拆解为多个子系统，使得各个部分可以独立迭代和部署。
多团队协作： 如果多个团队负责不同的业务模块，微前端可以有效地降低跨团队协作的复杂度，提升开发效率。
需要技术栈多样性的项目： 如果不同团队有不同的技术栈要求，微前端允许每个团队使用最适合自己需求的技术，而无需为统一技术栈妥协。
微前端可能存在的问题
系统复杂度： 微前端的实现往往伴随着较高的复杂性，尤其是在应用的集成、路由管理、状态共享等方面，需要付出额外的工作。
性能问题： 由于每个子应用都是独立加载的，可能会增加页面加载时间和资源消耗，从而影响整体性能。
开发和运维成本： 微前端带来的独立性虽然提升了开发的灵活性，但也增加了运维的难度。例如，多个子应用的版本管理、依赖管理等都需要专门的工具和流程来进行管理。

#现在前端的就业环境真的很差吗#   #牛客创作赏金赛#  #我的求职思考#