几年前微前端火得一塌糊涂。独立开发、独立部署、技术栈随便选，团队各干各的，听起来特别美。

现在风向变了。越来越多团队开始回头想：当初拆得那么碎，到底图什么？

一个明显的趋势是：微前端还在用，但更多团队正在往Monorepo走。不是回到以前那个乱糟糟的单体应用，是走向更清楚、更好管的单体仓库模式。

谁还在用微前端

微前端不是没用，是能用上的场景越来越少。现在还在用的主要是这几类：

超大型ToB平台，像阿里云控制台那种。功能模块是不同团队甚至第三方开发的，模块之间几乎没有UI状态共享。这种场景适合。

老系统重构的过渡期。这是微前端最合理的用法。老代码用jquery，新代码用react，两套东西要在一个页面里共存。微前端能让它们互不干扰，平稳过渡。

多技术栈的大公司。因为收购或者历史原因，公司里既有vue项目又有React项目，要强行整合到一个平台里。这时候微前端能当个缓冲。

微前端的隐性成本

对大多数中大型企业来说，微前端带来的麻烦比解决的问题多。

基建复杂好几倍。以前配一次Nginx就行的事，现在要管基座应用、JS沙箱、css隔离、多个子应用的CI/CD流水线、复杂的路由转发。这不是技术升级，是给自己找事。

跨应用通信特别麻烦。业务本身就是耦合的。用户登录态怎么同步？从A列表页跳到B详情页，得自己写一套复杂的状态同步机制。最后比直接在巨石应用里调函数还费劲。

用户体验有割裂感。经常是基座加载快，子应用加载慢，中间有明显等待。全局弹窗、深色模式这些细节很难统一，产品用起来像拼出来的。

Monorepo在回来

所以Monorepo又回到主流视野了。很多说放弃微前端的公司，不是退回乱糟糟的老代码，是换成了Monorepo加模块化的模式。

核心思路是：代码放一起，逻辑不耦合。用Turborepo、pnpm workspaces这些工具管起来，既保留模块化的好处，又享受统一仓库的方便。

Monorepo给前端工程化带来的价值很实在：

代码复用变简单了。微前端里要复用组件，得发版、升级、构建三步走。Monorepo里A应用直接本地路径引用packages/ui组件就行。改了源码，所有依赖立即生效，不用折腾版本管理。

依赖管理变清楚了。不用再面对"子应用用React 17，基座用React 18"这种依赖地狱。统一管理公共依赖，省磁盘空间，最重要的是技术栈统一了，团队能按同一套规范干活。

重构调试体验好多了。不用同时起基座和一堆子应用，所有代码都在本地。IDE的全局重构功能能用起来，跨包修改一次完成。这种代码级别的可控感，微前端给不了。

提交可以原子化了。一次修改涉及公共库和业务代码，一次提交全搞定。CI会自动识别哪些变了，只构建受影响的部分。代码库在任何时候都是自洽的，不会出现依赖断裂的问题。

没有银弹，只有权衡

微前端没死，在巨型SaaS平台和老系统改造这些特定场景里，它还有用。但对大多数追求高效协作和架构可控的团队来说，它的维护成本已经高过收益。

我们正在从物理隔离回到逻辑隔离。Monorepo受欢迎，是因为它用一个大仓库，换来了模块复用的便利和工程管理的确定性。它说了一个道理：

真正的解耦，不一定要把代码拆到不同仓库。把大家放在同一个屋檐下，但教会他们怎么保持房间整洁，才是更聪明的做法。

如果你的团队正在微前端的坑里爬不出来，可以考虑换条路走走。