上个月去南京软件谷跟三个做中后台的前端负责人喝咖啡，聊到最后大家拍桌子的点居然都绕在同一个东西上——微前端。有人说这玩意救了他们拖了三年的老系统，有人说这玩意把他们本来顺顺当当的发版流程搞得一团糟。
拆之前先想清楚你拆的到底是什么
很多人对微前端的第一印象，来自各种架构分享里的完美案例：单应用臃肿到维护不动，多团队并行开发互相掣肘，发版牵一发动全身，用了微前端之后所有问题迎刃而解。听多了就容易产生错觉，好像不上微前端，自己的前端架构就是落后的。
说白了，微前端的核心前提，是你的前端应用已经大到单仓库维护不动、多团队并行改代码经常打架、发版节奏完全绑死在同一条主线上。
我见过最离谱的团队，为了追技术热点，把一个10个页面的内部行政系统硬拆成4个微应用，光做沙箱隔离的配置就花了俩前端整整两周，最后日常改个表单的逻辑，还要跨三个仓库跳转提交PR，效率比之前单项目还低30%。这事儿没那么玄，不是你用了微前端，你就是完成了架构升级。
真的需要拆分的场景其实很窄：同一个域名下，同一个页面里，一半模块是三年前的老React15写的，一半是今年新上的Vue3写的，还有几个零散的jQuery写的老弹窗，每次改个导航栏都要把三个项目全跑一遍测试、发一遍版，这时候微前端才是真的能解决问题的工具。要是你的各个业务模块本来就是独立部署、独立访问的，中间连公共的导航和登录态都打通了，那跟微前端半毛钱关系没有。
你以为省下来的成本，其实都藏在看不见的地方
所有讲微前端的宣传稿，都会跟你说这玩意的好处：老系统不用重构，新团队随便上新技术栈，发版互不影响。听着特别美对吧？但你真落地了才知道坑在哪。
首先是沙箱的问题。老项目里的全局变量，跟新应用的变量撞了，你光调试样式冲突、弹窗层级错乱、路由跳转串的问题，就得耗掉小半个迭代的时间。然后是公共依赖的问题，你总不能每个子应用都打一遍React、Vue的核心包吧？光首屏加载的体积就能翻两三倍，用户打开个页面白屏三秒，后端团队的同学都要跑过来找你算账。
上次跟一个做支付系统的前端负责人聊，他说他们当初上微前端的时候，光解决支付页面的跨应用通信问题，就踩了三个月的坑——之前子应用里的支付成功回调，经常因为沙箱的作用域问题拿不到主应用传的参数，差点造成资损。
说白了，微前端从来不是“零成本重构”的捷径，它只是把你之前要一次性重构老系统的成本，拆成了每个迭代里持续要填的坑。你要是团队里没有一两个对沙箱原理、路由机制摸得透的人，劝你别轻易碰。
别被宣传稿骗了。真的。之前单项目出了问题，你从入口文件往下找逻辑，半小时就能定位。现在问题出在主应用和子应用的通信层，你得跨项目查日志，光复现问题的时间都够你写两个新功能了。
什么时候你根本不需要碰微前端
聊到最后大家总结出来，好多场景下，微前端根本帮不上忙，甚至会帮倒忙。
比如团队规模小于10个前端，项目整体的代码量不到10万行，拆什么拆？单仓库配个pnpm workspace，把公共组件抽出来，比你搭一套微前端的成本低太多了。再比如，你的各个业务模块本来就有独立的域名，用户进来根本不需要在同一个页面里来回跳，那你只要做个统一的登录态、统一的导航组件，根本不需要把所有模块都塞到同一个主应用里。还有那种最常见的，你团队里连基本的Code Review规范、发版流程都没理顺，之前发版还经常因为改了公共组件搞出全线上的故障，那你上微前端只会把问题放大——之前是一个项目发版出问题，现在是四个子应用随便哪个发版错了，都能把整个主站搞挂。
说实话，很多团队对微前端的期待，本质上是想找个一劳永逸的银弹。但哪有什么银弹啊。你团队里的协作流程没理顺，公共组件的沉淀没做好，哪怕你把系统拆成10个微应用，该出的问题还是会出。甚至因为拆分带来的通信、隔离、部署的额外成本，问题只会更多。
上次在南京的技术沙龙上，有个做SaaS的前端工程师站起来提问，说他们团队用了微前端之后，每个子应用都有自己的一套UI组件库，同一个页面上的按钮，三个子应用做了三种不同的圆角，用户看着都别扭。底下坐的人全在笑，因为大家都遇到过。
我见过很多团队把微前端用得特别好的，人家从来不会上来就说“我们用了最先进的架构”。人家的思路特别实在：主应用就干最核心的事，管路由、管导航、管登录态，子应用就按业务边界拆，每个子应用的代码量控制在两三万行，有专门的团队负责维护，公共依赖全部通过外部引入的方式共享，不重复打包。人家也不追求什么“所有新技术栈随便用”，大部分子应用都统一用同一个技术栈，只有个别实在拆不动的老系统，才用沙箱嵌进来。
真正好用的微前端，从来不是为了炫技，而是为了让每个团队能按自己的节奏干活，不用被别人的发版绑住手脚。