上周在南京的开发者聚会上，刚碰完三个做中后台的朋友，聊到最后全在吐槽同一个事——前端仓库越堆越重，发个版要等半小时，改个登录页的按钮样式还得协调三个不同的开发组。
先搞懂谁在被前端巨石压得喘不过气
很多人上来就搜微前端的搭建教程，根本不管自己的团队是不是真的到了需要拆应用的阶段。十几个人的小团队，项目总共没几个页面，上来就拆成五六个子应用，最后光搞路由适配就花了两周，纯纯给自己找事。
说白了，微前端解决的从来不是技术问题，是组织架构带来的协作问题。当你的代码仓库从最初的几百个文件，涨到上万行代码，构建一次要十几分钟，不同业务组的人改同一个公共组件，提交冲突要拉三四个群协调的时候，那种被巨石应用压得动不了的感觉，才是需要考虑拆分的起点。
之前接触过一个做企业服务的团队，三个开发组分别负责客户管理、订单、报表三个模块，最早全堆在一个React仓库里，每次发版要走三个组的交叉评审，有时候报表组改个图表组件，不小心把客户管理的搜索框搞崩了，排查半天才发现依赖版本冲突。折腾了大半年，最后上了微前端，把三个模块拆成独立的子应用，各自独立发版，不用再凑到同一个评审会上耗时间。
代价是什么？刚开始的三个月，光处理跨应用的通信、样式隔离、公共组件的版本同步，就占了两个前端一半的工作量。很多人只看到拆完之后发版快的好处，没人提刚开始那堆坑。
别被网上的方案模板骗了
打开技术社区搜微前端，十篇文章有八篇会列一堆方案的优劣势，什么运行时集成、构建时集成，好像选个靠前的方案，就能顺顺利利把应用拆完。真上手做过的人都知道，哪有那么简单。
很多人看了网上的教程，上来就选最火的方案，根本不考虑自己的场景。如果你们团队的技术栈全是统一的React，那模块联邦可能比带运行时的微容器轻很多，不用额外加沙箱的运行时开销，跨应用的组件复用也方便；要是不同组的技术栈都不一样，有Vue2、Vue3、React甚至还有老的jQuery写的遗留页面，那才需要带JS沙箱的方案兜底，不然全局变量串来串去，调试的时候能把人逼疯。
说真的，我见过太多团队为了上微前端而上微前端，最后搞出来的东西，子应用之间跳个转场要等两秒，点个按钮要加载半天，用户怨声载道，开发自己也烦。
没有放之四海皆准的微前端方案，只有匹配团队协作节奏的取舍。比如你要做样式隔离，用shadow DOM看起来很美好，最后发现第三方的弹窗组件根本挂不进去；给所有CSS加选择器前缀，写起来麻烦，漏一个就出现两个不一样的蓝色按钮。跨应用通信更麻烦，你用事件总线传数据，稍微没注意清理监听，就会出现内存泄漏；靠URL传参，复杂一点的对象根本塞不下。这些坑没有任何一个模板能给你标准答案，全靠自己踩一遍才知道怎么绕。
什么时候该踩刹车
不是所有的团队都需要微前端。
你团队总共不到十个人，所有代码都在同一个仓库里，大家对着同一个仓库发版，最多等个十分钟构建，那真没必要搞微前端。你把拆出来的那些构建配置、路由跳转的逻辑省下来，多写两个核心功能不香吗？
要是你的业务模块之间耦合特别深，比如用户点个订单详情，要同时拉取客户的信息、历史订单、售后记录，这些模块拆成独立子应用之后，跨应用的接口调用、数据同步的复杂度，比之前在同一个仓库里高十倍，那这种拆分就是得不偿失。
当你的构建时间超过20分钟，跨组的代码评审冲突率超过30%，不同模块的发版节奏完全错开的时候，微前端才是值得考虑的选项。
上次碰到个创业团队的前端负责人，说他们公司才20个人，前端总共4个，非要跟风上微前端，说要做‘可扩展的架构’，最后搞了三个月，项目跑起来内存占了快1G，打开个页面要加载十几兆的JS，老板问为什么速度变慢了，他还在说这是为了未来的扩展性。未来？等他们真的有20个前端的时候，说不定现在写的这些代码早被推翻重写了。
这事没那么玄。微前端从来不是什么架构上的银弹，说白了就是把之前单仓库里的墙，拆成了每个子应用自己的墙。墙拆的好不好，从来不是看你用了多先进的技术方案，是看你拆完之后，大家协作是不是真的变轻松了，发版是不是真的不用等所有人凑齐了，出了问题是不是能快速定位到对应的模块。要是拆完之后大家反而要花更多时间处理跨应用的破事，那还不如回到最初的巨石应用，至少改代码的时候不用考虑沙箱会不会把全局变量搞混。