SmartX测试实习面试

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