微前端

微前端方案利弊

“微前端”这个概念刚出来的时候火了一阵子，现在继续提“微前端”的人已经很少了。从招聘软件的职位描述里可以很明显的感觉到几乎没人提“微前端”了，这是用脚投票实打实得投出来的结果——因为大部分项目都不需要使用微前端。

微前端解决的是什么问题？大部分人会这么说：

• 将大项目拆分成小项目，避免巨无霸项目的编译耗时问题。
• 允许每个小项目使用不同的技术栈，方便逐步升级。
• 每个小项目可以独立发布，风险隔离。
• 多个前端项目在用户侧交互起来像是一个前端项目。

如果再和“不使用微前端，直接使用多个独立前端项目，彼此之间通过 URL 跳转”这种朴素方案对比的话，其实就只有最后一个优点是成立的了。

那这个优点是我们的业务痛点吗？好像是的。但是让我们来看一个场景：你随便打开一个你觉得最复杂的手机 APP 或者PC端的 Web app，你点进去之后你平时经常浏览的页面有几个？根本就没几个页面！而且事实上就算把不常访问的页面都算上，一般也没几个页面。实际上，用户对于低频访问的页面，是不介意多一次明显的页面跳转的，用户只对高频访问的页面的交互体验敏感。比如，对于一个互联网金融项目而言，用户做风险测评和做账户开户这两个操作都是低频操作。大部分项目，完全可以这样设计：

• 高频访问的页面放到一个独立项目里。
• 低频访问的页面按相关性拆分成多个独立项目。

这样就可以避免微前端方案带来的一系列弊端了。