微前端

微前端是一种将大型复杂的前端代码库拆分成简单、可组合、独立交付的应用的架构模式。它借鉴了后端微服务的思想，让前端应用也能实现团队自治、独立部署和技术栈多样化。

核心概念

"微前端是将前端单体应用拆分为多个更小、更简单的应用，这些应用可以由不同的团队独立开发、测试和部署，最终组合在一起为用户提供统一的体验。"

微前端的核心思想是分解与组合：

分解：将大型前端应用按业务域或功能模块拆分为多个小型应用
组合：通过某种机制将多个小型应用组合成一个完整的用户体验

核心优势

渐进式升级

微前端允许你逐步迁移现有应用，而不是一次性重写。你可以：

在旧应用中逐步引入新功能
采用新技术栈开发新功能，与旧代码共存
逐步淘汰技术债，而不是冒险的大爆炸式重写

简单、解耦的代码库

每个微前端应用都是一个独立的代码库：

代码库更小，更容易理解和维护
团队拥有完整的代码所有权
减少了合并冲突和协调成本

独立部署

每个微前端应用可以独立部署：

一个应用的更新不需要重新部署整个系统
发布周期更短，反馈更快
故障隔离，一个问题不会影响整个系统

团队自治

不同团队可以拥有不同的微前端应用：

选择自己熟悉的技术栈
独立制定开发节奏和发布计划
减少跨团队协作的摩擦

集成方式

微前端有多种集成方式，各有优缺点：

方式	优点	缺点	适用场景
服务端模板组合	SEO 友好、首屏快	需要服务端支持	内容驱动的网站
构建时集成	简单直接	耦合度高、无法独立部署	小型项目、内部系统
iframe	隔离性最好、最简单	性能差、体验割裂	快速集成第三方系统
JavaScript 运行时集成	灵活、独立部署	复杂度高	大型 SPA 应用
Web Components	原生支持、标准化	浏览器兼容性	现代浏览器环境

常见问题

样式隔离

不同微前端应用的样式可能会相互影响，常见的解决方案：

CSS Modules
Shadow DOM
命名约定（如 BEM）
样式作用域工具

共享依赖

避免重复加载公共库：

外部化共享依赖（CDN）
Module Federation
微前端框架的依赖共享机制

应用间通信

微前端应用之间需要通信时：

自定义事件：适合简单通信
状态管理：通过共享状态管理库
路由参数：通过 URL 传递数据
消息总线：构建统一的消息中间层

公共组件

提取共享的业务组件：

独立的组件库项目
统一的 npm 包
微前端框架的组件共享机制

权衡考虑

微前端并非银弹，引入它会带来新的复杂性：

包体积增加：每个应用都有自己的依赖
环境差异：不同应用的技术栈差异带来维护成本
运维复杂度：需要管理更多的部署单元和版本

建议：如果你的应用规模还不大，团队协作顺畅，不要急于引入微前端。当以下情况出现时再考虑：

代码库已经大到难以维护
多个团队频繁在同一个代码库中冲突
需要支持多种技术栈共存

文章列表

方案对比

方案对比表格 - 从隔离性、性能、依赖共享等维度对比 iframe、Web Components、JS Entry、HTML Entry、Module Federation 五种方案
HTML Entry vs JS Entry - 两种子应用加载方式的原理差异与选型建议
UMD 的必要性 - JS Entry 和 HTML Entry 对子应用打包格式的要求差异

框架学习

Single-SPA 框架 - 微前端框架鼻祖的核心概念、生命周期函数与实现原理

Qiankun

两种加载模式 - registerMicroApps 与 loadMicroApp 的技术原理对比与适用场景分析
通信与路由方案 - 基于 Pinia 的主子应用通信方案与路由跳转最佳实践
实战踩坑历程 - 企业级中后台系统微前端改造的完整踩坑记录与解决方案

Micro-app

从零到一实现指南 - 企业级 micro-app 微前端模板的完整实现过程与最佳实践
部署指南 - 同域部署与跨域部署的配置方案与注意事项

实践经验

微前端改造实践 - 多个独立项目整合到微前端架构的完整过程，涵盖方案选型、技术实现与踩坑经验
版本更新检测方案 - 微前端场景下如何实现版本更新检测与用户刷新提示

微前端 ​

核心概念 ​

核心优势 ​

渐进式升级 ​

简单、解耦的代码库 ​

独立部署 ​

团队自治 ​

集成方式 ​

常见问题 ​

样式隔离 ​

共享依赖 ​

应用间通信 ​

公共组件 ​

权衡考虑 ​

文章列表 ​

方案对比 ​

框架学习 ​

Qiankun ​

Micro-app ​

实践经验 ​

相关资源 ​

微前端