上个月，我们默默地把三个微前端子应用合并回了两个。没有发公告，没有写技术复盘，就是安安静静地把代码挪了回去，删掉了两个仓库，关掉了四条CI流水线。

如果有人在半年前问我"微前端到底好不好"，我大概率会给他列一堆优点：独立部署、技术栈无关、团队自治。但现在我的回答变了：看你的团队到底有没有拆的必要。

这个判断听起来像废话，但我见过太多团队在这件事上栽跟头，包括我自己。

拆的时候有多爽，合的时候就有多痛

故事的开始总是相似的。一个大型前端项目，十几个开发者在同一个仓库里撞来撞去，merge冲突是家常便饭，发版节奏互相牵制。有人提了微前端，方案评审会上大家眼睛都亮了——每个团队自己的子应用、自己的发布节奏、自己的技术栈，互不干扰，多美好。

我们也是这么想的。2024年初，基于qiankun把主应用拆成了五个子应用，按业务域划分。前半年确实爽：团队A改了代码不用等团队B review，团队C想用新版本的React自己升，团队D甚至单独搞了一套构建流程。

问题是从第二年开始集中爆发的。

第一个信号是联调成本。五个子应用共享用户状态、共享路由、共享一部分业务数据。听起来"共享"是个微前端应该解决的问题，但实际上，当你把状态管理从一个应用拆到五个应用之后，"共享"就变成了"同步"——你得保证五个独立运行的子应用，在任何时刻对同一份数据的理解是一致的。这件事的难度，比拆之前至少翻了三倍。

第二个信号是用户体验的一致性。设计团队出了一套新的交互规范，要改一个全局的弹窗组件。以前一个仓库改一处就完事了，现在要改五个仓库，发五次版，还要祈祷五个团队的发版窗口能对齐。有几次用户在不同页面看到了两种样式的弹窗，客诉就是这么来的。

第三个信号，也是最隐蔽的一个：知识碎片化。每个子应用有自己的业务逻辑、自己的技术选型、自己的踩坑记录。时间一长，没人说得清楚整个系统的全貌。新来的同学只能看到自己负责的那块，全局架构成了团队里几个老人的"脑内知识"。这不是微前端的bug，但它确实是一个被严重低估的成本。

大部分团队拆微前端，是因为"别人都在拆"

我后来反思，当初决定拆微前端的动机里，有多少是真实的业务需求，有多少是技术焦虑。

说实话，大概五五开。

当时的真实痛点是什么？代码冲突多、发版互相阻塞。这两个问题的本质是协作效率问题。但协作效率问题，不一定需要架构层面的拆分来解决。monorepo配合合理的目录规范和CI策略，也能解决大部分问题。我们当时其实已经用了monorepo，但觉得"还不够"——这种"还不够"的感觉，很大程度上是被技术社区的叙事推着走的。

技术社区有一种很强的叙事倾向：把复杂问题简化成一个"正确答案"。微服务是后端领域的"正确答案"，微前端是前端领域的"正确答案"。但现实是，大部分正确答案都有前提条件，而这些前提条件往往比答案本身更重要。

微前端的真正适用场景，我现在的判断标准很简单：如果你的团队满足了以下条件中的至少两个，可以考虑拆；如果一个都不满足，大概率是在制造问题——

- 团队规模超过30人，且分布在不同的地理位置

- 子业务之间有明确且稳定的边界，半年内不会有大调整

- 不同团队有不同的发布节奏需求，且这种需求是刚性的（比如合规要求）

- 子应用之间几乎没有共享状态和共享UI组件

回头看看我们自己，五个子应用里有三个共享了超过40%的组件和状态，团队总共才12个人，业务边界还在快速变化。这种条件下拆微前端，就像用航母编队去打渔——能力过剩，协调成本反而更高。

往回收比拆出去难十倍

把三个子应用合回两个，说起来轻巧，做起来花了将近两个月。

最难的部分不是代码迁移，是状态合并。五个子应用各自维护了一部分用户状态，合并之后要保证行为一致，要处理边界情况，要确保不会有状态丢失。这块工作量占了整个合并周期的60%。

其次是构建流程的重构。每个子应用都有自己的webpack/rspack配置、自己的环境变量、自己的部署脚本。合并之后要统一构建流程，但又不想丢掉各个子应用在构建优化上做的那些工作。最后是折中方案：核心配置统一，差异化配置通过环境变量注入。

还有一个意想不到的阻力：人的惯性。每个子应用的owner对自己那块代码有感情，合并意味着他要跟别人共享"自己的"代码，要接受别人的代码风格和技术选择。这不是技术问题，是人的问题，但往往是最难处理的。

一个不太舒服的结论

经过这一轮拆分再合并，我得出了一个让自己不太舒服的结论：对于大部分中小团队来说，前端架构演进的方向，不应该是越来越分散，而是越来越内聚。

monorepo、模块化、设计系统——这些让代码更内聚的工具，在大多数场景下比微前端更实用。它们的共同特点是：降低协调成本，而不是用架构手段绕过协调问题。

微前端不是不好。在超大规模团队里（比如蚂蚁内部的某些业务线），它确实是解决协作效率的利器。但"利器"这个词本身就暗示了使用门槛——你不会把手术刀推荐给所有人，哪怕它确实能治病。

所以如果有人问我"要不要上微前端"，我现在的回答是：先把你能用的简单手段都试一遍，如果还是不行，再考虑拆。拆了之后如果发现问题比收益大，及时收回来也不丢人。

架构决策没有面子问题，只有成本收益问题。死撑一个不合适的架构，才是真正的面子问题。