拆完巨石前端我才看懂微前端的真实分量

去年在某中厂待过的项目组，之前攒了三年的前端代码，打包一次要14分钟。本地起个服务改个按钮样式，等热更新等得能冲完一杯手冲。没人敢动公共组件，谁改谁背锅，全组人都在等一个”拆分方案”。

先搞清楚我们当初为什么要拆巨石

之前大家凑在一个仓库里写代码的好处是改东西快，坏处是快到所有人的提交都能把别人的功能搞崩。有次运营提了个活动页需求，开发刚写完上传，把原本稳定跑了半年的支付页搞白屏。全组加班到凌晨两点查问题，最后发现是有人在公共的utils文件里改了个格式化函数，没同步测试。

那时候所有人都憋着一股劲，要把这个拧成一团的代码拆开。最开始大家对标的方案就是微前端，想象中它能解决所有问题：不同业务线自己维护自己的应用，想用React用React，想用Vue用Vue，部署互不影响，打包快，再也不用为别人的bug背锅。

真落地的时候才知道麻烦全在看不见的地方

最先撞上的是路由。一开始想的是主子应用靠路径前缀划分就行，等真接了三个子应用，发现有个老项目自己内部的路由是hash模式，主应用是history模式，切来切去刷新就404。折腾了快一周才把路由同步的逻辑理顺，转头又被样式问题打了回来。主应用的全局重置样式一加载，直接把子应用的按钮圆角全改没了。一开始想的是给每个子应用的样式加个特殊前缀，后来发现老项目里写了快两千个内联样式，改前缀的工作量比重写还大。

所谓的”技术栈完全自由”，本质上是要你自己承担所有跨应用的兼容成本。还有资源加载的隐形坑。子应用用的是React17，主应用用的是React18，本来想做依赖共享，结果发现版本差了两个大版本，共享的话直接报hooks的错。不共享？那每个子应用都要把React全量打进去，本来一个页面加载JS是200K，拆完三个子应用之后，光框架代码就加了1.2M，首屏加载反而比之前的巨石应用慢了30%。当时组里有人拍桌子，说这拆了个啥啊。

别把微前端当成必须上的标准答案

这事没那么玄。很多人一提微前端就觉得是高级架构，是大厂标配，实际上你算算账：如果你的前端团队总共就三个人，业务也就两个模块，那抱着巨石仓库写反而效率更高。拆微前端要额外搭主应用的框架，要做路由、样式、JS的隔离，要处理跨应用的通信，这些都是额外的维护成本，不是天上掉下来的。之前接触过一个电商团队，一共五个人，硬要跟风上微前端，花了三个月搭了主应用框架，最后发现每个子应用的代码量还不到原来的三分之一，光维护主应用的隔离逻辑就占了两个人的工作量，最后又把代码合回了一个仓库，白折腾三个月。

那什么时候真的需要微前端？你有超过三个独立的业务团队，每个团队的发布节奏完全错开，之前的巨石仓库已经到了改不动的程度——比如打包超过10分钟，每次发版要全组人等着对齐时间，要全量回归所有业务，那微前端才是真的能解决问题的方案。说白了，它是一个匹配组织分工的工具，不是技术炫技的玩具。上次和那个之前踩坑的项目组聊天，他们最后没有追求完全的技术栈自由，而是统一了所有子应用的技术栈版本，只保留了独立部署的能力，打包时间从14分钟降到了2分钟，发版再也不用全组人蹲在群里等同步按钮，这才是真的把微前端用对了地方。别总想着一步到位搞最灵活的架构。能解决你当下最痛的那个问题，就够了。

拆完巨石前端我才看懂微前端的真实分量

先搞清楚我们当初为什么要拆巨石

真落地的时候才知道麻烦全在看不见的地方

别把微前端当成必须上的标准答案

文章目录

最新文章

热门标签