定义

Monorepo（单仓多包） 是仓库层的组织方式：多个包/应用在同一个 Git 仓库里，解决代码同步、公共组件共享、跨项目 refactor 的协作问题。工作在编译时 / 仓库层。

微前端（micro-frontend） 是运行时架构：把庞大单体拆成多个可独立开发、测试、部署的微型前端，由宿主在运行时组装。工作在运行时 / 架构层。

两者常组合使用：Monorepo 管本地开发与共享依赖，微前端管线上独立部署与技术栈解耦。

核心痛点：迁移壁垒

前端项目做大后，换技术栈的隐性成本往往高于改代码本身：学习曲线、生态绑定、与框架生命周期的深层耦合、数据与结构迁移惯性。设计阶段可留后路：

  • 依赖倒置：面向接口编程，核心业务逻辑尽量与框架解耦（Vanilla JS / 纯业务层）
  • 框架只做渲染层，降低日后替换成本

分层对照

概念 层级 解决什么问题
Monorepo 编译时 / 仓库层 多仓库同步难、公共组件难共享
微前端 运行时 / 架构层 应用臃肿、技术栈锁定、发布排队、多团队冲突
模块联邦 运行时 / 构建层（轻量变体） 运行时拼装组件/模块，避免重复打包

微前端技术核心

  • 应用路由分发
  • 应用隔离（样式与 JS 沙箱）
  • 跨应用通信
  • 依赖共享（也带来版本冲突风险）

代价与轻量替代

微前端运维与心智负担重：反向代理、独立 CI/CD、重复加载框架 Runtime、沙箱 Proxy 损耗、跨应用调试困难。

中小项目可优先考虑：

  • 多页应用（MPA）物理切割
  • Webpack 5 / Vite 模块联邦（组件级运行时拼装）
  • 纯 Monorepo + 依赖倒置，不引入完整微前端基建

何时值得上微前端

技术架构是组织架构的映射。

当团队规模、协作内耗、发布排队的痛苦明显超过维护微前端基建的成本时，微前端才可能是解药。大厂（如支付宝 / qiankun 团队）能玩转，往往依赖预加载、自动化研发平台、设计规范等顶层基建托底。

来源

相关

维护：Cursor Agent，2026-06-30。