之前我们公司有同事想要试一下在项目中应用微前端，我不确定他是如何去考量的，可能从项目角度觉得项目很大，也可能是从项目性质角度觉得用微前端比较合适，也可能是想要尝试一下新技术，但不管如何，这也让我思考了一下从哪方面考量项目是否适合应用微前端架构。
参考文章：
从微服务概念衍生出来的前端项目解决方案：将单一的大型应用，分解为几个小应用，并通过技术手段将其组合为一个应用，微前端是一个项目架构，一个解决巨石应用的实现方案，他是组织项目的一种方式
应用微前端的考量
从微前端目前的一些技术方案和项目实际需求出发，我总结了以下几个使用微前端的考量点：
是否存在适合拆分为比较独立的业务
如果你的项目可以拆分为几个业务逻辑相对比较独立的部分时。则可以考虑应用微前端。因为从受微服务启发的微前端，自然也需要符合微服务的一些基本特征，而微服务的一个特点就是业务耦合比较小，因为微服中的服务职责单一，我认为只有当你的业务可以被拆分为相对独立的不同部分时，应用微前端才会比较合适，否则，即使你强行应用微前端，那么这几个拆分出去的业务之间的通信和交互问题，可能会给你带来不弱于单独项目本身的复杂性。
项目是否膨胀到了一定地步
如果你的项目足够大，业务多，有向巨石应用发展的趋势，且越来越不好维护时（甚至存在多团队维护一个项目等等），这时候你可以考虑应用微前端。
但是，就几个功能业务的小项目来说，完全没有必要使用微前端，不要说什么为了后续的业务快速发展在一开始就选用微前端，如果业务快速发展，功能变多，先优先考虑如何将项目的组件、功能、业务进行良好的划分、处理好公共代码抽离、逻辑复用，业务间减少耦合等代码工程方面的角度去考虑。等真的发展到一定阶段了，再考虑重构，而且，之前的那些考虑其实也能利于项目后续重构和维护。
技术架构需要升级
当你想要为项目做技术架构升级时，而庞大的项目无法一次性全部升级完时，即新旧架构或者新旧技术栈想要共存时。可以考虑应用微前端。
其他的考虑
- 不同业务之间需要沙箱隔离
总结
我认为，这个技术的应用需要有实际的需求，从他解决的是什么问题，是否适合这个场景来进行评估，不要为了微前端而微前端。