缘由
单纯从分析系统整体布局来看，跟使用微前端改造完的项目几乎是一模一样。在入职后的一段时间内，我确实想过是否要提议内部用微前端来解决一些问题。本次调研的时间是2021年12月，是近期补充的调研文档，相关问题或许官方已完成修复。
微前端或许能给我们带来什么？
- 只需要维护一个登录页
现在每个系统都有一个登录页，如果需要对登录页的UI、文案或功能进行修改的话，我们需要改到所有的仓库。假设使用微前端，我们可以把登录页跟导航栏放在主应用里。本地开发的时候，只需要把主应用跟需要开发的子应用跑起来，一个登录页就可以供多个子应用去使用了
- 本地开发的时候可实现主系统、子系统之间的相互跳转，生产上不需要通过新开页面的方式
以微前端半壁江山 qiankun为例，一旦浏览器的 url 发生变化，便会自动触发 qiankun 的匹配逻辑，所有 activeRule 规则匹配上的微应用就会被插入到指定的 container 中，同时依次调用微应用暴露出的生命周期钩子。
- 实现多个系统之间的通讯与数据共享
不管是 qiankun 还是 microApp ，或是其他的微前端框架，都会提供相应的方案让我们进行各个应用之间的通讯。比如半壁江山的initGlobalState。听起来很棒！
- （最大卖点）用不同技术栈开发同一个系统
主应用不限制接入应用的技术栈，子应用具备完全自主权。同时也解决单体应用在一个相对长的时间跨度下，由于参与的人员、团队的增多、变迁，从一个普通应用演变成一个巨石应用后，随之而来的应用不可维护的问题。
- 依赖共享
不少社区活跃的开发者在介绍微前端，在自己的实践经历后，都建议使用同一版本的库，并将这些公共依赖配置成 external。你看，这样一来，小而美的应用不就出来了？
- 一个系统多个模块，支持独立部署
这个就不做多余的解释了
但或许它并不是一个完美的解决方案
- 他可能是一个伪需求
不同团队不同技术栈开发同一个系统，这种情况会不会存在？一定会，但是普遍吗？并不普遍。 不同技术栈团队通常都是分开开发各自的系统的，然后通过子系统跳转，这已经是遍地开花的事。而且我们真的需要在一个系统的开发中，部分模块用vue+element，部分模块用react + antd 吗？ 别说vue跟react的两开花，要知道我们在规范里面，已经明确要统一库生态。当然这不只是我们团队这样，大多数团队也都是遵循这样的规范的
- 并不建议依赖共享
我在一些社区看到有不少实践者提出这个依赖共享的时候，我是困惑的。在同一个项目中使用不同技术栈的解决方案里，又提出了使用同一个版本（你咋还限制版本了呢？）方便共享依赖。这不是有病吗？ 查看了文档后发现，qiankun虽然是半壁江山，但是也不是肆意妄为的，人家也不建议你这样做，并表示qiankun 2.0 版本将提供一种更智能的方式使其自动化。同时也引用了微前端的官网 https://micro-frontends.org/ 里的一些想法
Don’t share a runtime, even if all teams use the same framework. Build independent apps that are self contained. Don’t rely on shared state or global variables.
- 项目显得臃肿，也不好维护
qiankun的启动代码不少，严格来说对应用的性能是有一定的损伤的！子应用用的通用三方框架，因为应用隔离，比如三个子应用均使用了element，子应用跳转的时候都会拉取自己vendor打包的出的js，所以整个系统会显得非常臃肿。子应用的js静态资源还是通过xhr方式去拉取，看接口又不方便。所以如果不是必须得用微前端，我们真的没必要！ 微前端在一定程度上还是提供了便利的，所以好多团队在引入微前端之后都开始滥用，最后用烂了！当时在询问朋友对微前端的实践有什么看法，我一个朋友跟我吐槽他们公司一个后台系统拆了18个前端工程，这一类事情在社区也确实没少见。
我们需要微前端给我们带来的便利吗
- 取消每个子系统的登录页面
统一登录页面是我们必然要做的一件事，但是解决这个问题的办法并不是只有微前端。我们可以使用Single Sign On的方式，用户只需一次登录就可以访问所有相互信任的应用系统。SSO依然是当前比较流行的做法！
- 数据共享/通讯
我们内部本身也没有太多的通讯困难的问题，如果哪天我们真的需要跨系统数据共享，大不了我们内部开发sdk去实现呗！
- 主系统可以新开窗口跳去子系统，但反过来不行
如果要解决这个问题，多个系统共用同一套路由的配置即可，但是如果这样做我真的会谢！每次需要往一个系统加一个新页面路径，我就得想瓜田里的猹一样跳来跳去，发布时还得打包n次 这个是我最开始想引用微前端的原因，但其实这不是一个系统，这他喵是三个系统！把它们放到一个导航栏里面只是我们产品呈现的一种形式而已，他的本质就是多个系统！ 我们不喜欢在主系统里面还要维护子系统的路由，这些都是后续可以从产品的角度上去优化的。等到哪天每个子系统的目录结构真庞大到吓人，拆开是必然的！所以咱就先不必纠结这个开发/交互体验不好的问题。
微前端会像后端的微服务一样，成为一种趋势吗
请问老师述说微前端的趋势？
程劭非（winter）：微前端我觉得它其实没有太多的趋势。首先微前端就不是一个大家都要用的。微前端沾了微服务的光，但是微服务是所有后端基本上都要往架构上迁，微前端很明显不是这样的。 它更多的是单页应用并有多框架隔离的需求，然后做出微前端这样的一个技术方案。我觉得说是刷，微前端就不该这么热，包括很多学生都会问我微前端，我反问你有么有看过微前端解决什么样的内容？如果非要往这上边靠的话，就相当于没有困难创造困难也要上，举个例子，公司一共有四五个前端，就非要用微前端架构，四五个人都可以用不同框架，这其实是没必要的
写在最后
其实我不是一个微前端的仇恨者，反而我在入职最早期就提出是否要使用微前端。但只是在调研后发现，我们并不需要微前端，但很多人是为了用上微前端而使用微前端，也没理解微前端的使用场景，诶，就是滥用，甚至一知半解就开始在社区复制粘贴，以讹传讹。
微前端真正适用的是什么场景，这是今年4月 qiankun 的主要开发者在infoQ给出了回答。
InfoQ：你认为哪些场景下适合采用微前端，哪些场景不适合呢？ 刘奎：回答这个问题之前，我们可能要先来回答一下微前端解决了什么问题。
从工程角度来看，微前端其实解决的是在前端技术高速迭代、组织架构频繁变更的背景下，如何通过一些物理隔离的手段降低系统组件间的耦合，从而确保每个组件的开发独立、交付独立，进而实现整个系统渐进式演进的能力。
从产品角度来看，微前端解决的是如何在技术栈无感知的情况下，实现整个产品的平台性及动态性。针对不同的场景及用户角色，动态地将来自不同系统的服务组装起来。
明白了这两个要点，我们就能回答这个问题了，简单来说就是：
如果你不是要在一个长尾应用上做持续交付，你就不需要微****前端****；如果你的产品都是同一个小的团队开发的，你就不需要微前端；如果你的产品没有集成 / 被集成的诉求，你就不需要微前端。反之亦然。
