微前端落地的那些实在账

上周去杭州跟几个做ToB的前端团队聊，一半以上都在啃微前端的方案，还有两个已经踩了快半年的坑，预算超了三分之一，还没把最后一个老系统迁完。

这事没那么玄。没人放着好好的单体应用不用，非要折腾拆分。

没人是为了追技术潮流上微前端的

跟我聊的那个团队，之前的系统是个彻头彻尾的大杂烩。五年前写的老CRM用Vue2搭的，新上线的运营后台团队选了React18，中间夹着个客户标签管理的小模块，还是早期工程师用jQuery堆的，三部分代码全塞在同一个Git仓库里。

之前的发版流程有多离谱？一个前端改个按钮的边距，要拉群等半小时，确认这个样式不会影响老CRM的弹窗，不会搞乱运营后台的表格。发一次版要走两小时的流水线，万一出问题回滚，三个模块的代码一起回，谁的改动被带回去了都不知道。

说白了，就是被发版耦合逼到份上了，才想着找个拆分的方案。一开始他们也考虑过直接把仓库拆成三个独立的项目，后来发现三个系统的入口都在同一个门户里，用户点个导航就要跳三次页面，体验差到被业务部门投诉到CEO那里，这才转头选了微前端。

拆完才发现要补的窟窿比想象多

一开始所有人都觉得，拆完之后各发各的版，再也不用等别人排期了，效率至少提三倍。真接进主应用才发现，之前想当然的问题全冒出来了。

最先踩的就是样式隔离的坑。一开始看宣传说用shadow DOM就能搞定所有样式冲突，结果那个jQuery写的老模块，里面的弹窗是直接挂在body标签下面的，shadow DOM根本挡不住。上线第一天就出问题：用户点了弹窗，整个页面的按钮padding全被老模块的全局样式改了，排查了三天才找到根源——老模块里的代码当年写的时候就没加过任何样式隔离的类名，全局把所有button的样式都重写了一遍。

还有公共资源加载的问题。三个子应用都引了lodash库，一开始图省事，每个子应用打包的时候都把lodash打进去，主应用加载的时候，光重复的lodash代码就下了三次，首屏加载时间直接慢了两秒，运营团队说后台打开要等半天，用户都嫌烦。想抽成公共依赖从主应用加载吧，老的jQuery模块根本没接打包工具，直接引的CDN上的lodash，版本号和另外两个子应用用的差了三个大版本，函数调用直接报错，又折腾了一周才把版本对齐。

别把微前端当解决所有问题的补丁

我见过太多团队的选型逻辑是：出了线上事故，CTO要求优化架构，团队搜一圈现在前端圈流行什么，看到微前端的宣传说能拆分应用、独立发版，就直接照着方案搭。根本没算过自己要付的成本。

有个更离谱的团队，整个前端组就三个人，所有代码都是同一个人写的，技术栈全统一，发版流水线跑一次只要五分钟。就因为看同行都在搞微前端，硬拆了三个月，最后发现跨应用通信要写额外的适配代码，路由跳转要做额外的缓存处理，基座维护成本比之前维护整个单体应用还高，最后又把所有代码合并回了同一个仓库，之前花的三个月人力，全打了水漂。

真的不是所有团队都适合上微前端。如果你的系统只有一两个前端维护，技术栈统一，发版节奏一致，根本没必要凑这个热闹。微前端真正适合的场景，是那种有多个独立业务线，每个业务线有自己的前端团队，技术栈不统一，发版节奏差很多的系统——比如企业内部的门户，HR模块一个月发一次版，销售模块一周发三次版，财务模块半年才更一次，这种场景下用微前端把发版的耦合解开，才是真的解决问题。

上次跟那个踩了半年坑的团队聊天，他们现在已经把微前端的接入文档改了三版，所有踩过的坑都写得明明白白，新人进来先读文档，别上来就瞎拆。说白了，先把自己的问题摸透，再选架构，别上来就抄别人的作业。