微前端是一种由独立拥有和可部署的前端应用组成的用户界面。这种方法是Thoughtworks正式提出的， 2016和一个 2024 调查显示 23.6% 的受访者在前一年使用微前端的比例为 75.4% % 2022. 前端状态报告
你可能已经遇到这个问题了。三个产品团队共享一个前端仓库，等待同一发布列车，即使一个团队正在修改结账流程，另一个团队正在更新用户资料，第三个团队正在调整营销页面。微前端架构将这些产品区域分离开来，使团队可以独立拥有、测试和发布它们，同时用户仍然体验到一个应用程序。
这个区别很重要。微前端不是更小的文件夹、组件或包。它的核心目的在于 组织和发布的独立性，由技术边界来支持明确的拥有权。这个架构可以消除协调瓶颈，但也会引入运行时集成、依赖管理、测试、安全性和性能责任。
目录
理解微前端概念
从一个前端到多个拥有的应用
传统的前端通常只有一个仓库、一个构建和一个部署边界。即使code被分成干净的特性文件夹，负责这些文件夹的团队仍可能依赖相同的管道和发布计划。一个小的变化在一个区域可能会触发整个应用的构建、共享回归测试和每个团队的协调。
微前端将浏览器应用分成 业务能力。checkout团队负责checkout，profile团队负责账户设置，营销团队负责促销内容。每个片段都可以有自己的代码库、交付流程和发布节奏，然后通过一个壳或组合层成为更大的体验的一部分。
马丁·福勒(Martin Fowler)将该模式定义为 “一个架构风格，其中独立可交付的前端应用程序被组合成更大的整体” 在他的基础 微前端架构指南。
一组疲劳的办公室工人坐在桌子上，手里拿着代表不同微前端开发团队的纸张。
一个组合商店的类比
想象一个百货商店。一个团队管理门店，另一个团队负责收银台，另一个团队负责退货。顾客看到一个商店，但每个区域都有不同的流程、责任和人员。微前端与此类似：浏览器渲染一个产品体验，而几个团队在幕后操作不同的界面区域。
该术语与将微服务思维延伸到浏览器相关联 Thoughtworks 在其 2016 年 11 月的技术雷达中突出了它 后来福勒记录了它从评估到试验并最终采用，这描述了模式从一种新兴技术向更为成熟的架构选项的发展 对于更广泛的实用概述，Nerdify 提供了可扩展的 Web 开发将该模式与邻近的方法进行比较，例如插件架构，这在本指南中讨论 插件架构指南.
重要的教训是微前端不是每个界面都需要的默认升级。它们只有在团队边界和发布边界造成真正的痛苦时才有意义。只有当这种独立性值得管理更多的合同、资产、运行时故障模式和运营工具时，成本才会得到合理化
微前端架构的工作原理
壳和碎片
一个工作系统通常从一个 应用壳也称为容器或调度器。壳渲染公共布局，建立路由，提供身份验证上下文，并提供共享界面元素，如导航或通知。它还决定哪个微前端需要加载，并且该碎片应该在哪里挂载
每个片段都是独立维护的应用。它可能位于单独的仓库中，使用自己的CI管道，发布自己的版本，并暴露一个捆绑包、片段、Web组件或远程模块。shell在浏览器中组合这些片段，可能是在页面加载时，或者当一个路由需要它们时。
边界只有在团队可以依赖它时才有用。shell和每个片段都需要明确的合同，涵盖挂载行为、路由所有权、加载状态、错误处理、设计令牌、可访问性期望和支持的依赖版本。
实践规则： 分享合同和视觉原语有意为之。不要仅仅因为两个团队当前使用相同的框架就分享运行时实现细节。
不重复造轮子的沟通
片段有时需要通信。一个结账片段可能需要知道用户已经登录，而一个个人资料片段可能需要发布一个账户更新事件。团队可以使用自定义浏览器事件、共享存储、URL参数或注入服务。
每个选项都创建了一个不同的耦合配置：
- 自定义事件 保持所有权分开，但团队必须记录事件名称、数据结构和时间。
- 共享存储 简化协调状态，但它们可能会重建中央依赖图表，这正是架构试图减少的东西。
- URL参数 对于导航和可共享状态来说，URL参数是很好的选择，但并不是每种交互都适用。
- 注入服务 提供控制的能力，但壳必须维护这些服务的契约。
壳应该只协调属于整个应用程序的部分。如果它变得负责每个片段的状态和商业规则，它就变成了一个更复杂的部署过程的分布式大型应用程序。
根据Fowler的历史进程所记录的，为什么这种模式经常与微服务进行比较。两种方法都分离了所有权和交付，但微前端将这种独立性应用到了浏览器界面。在当前的工具中 模块联邦使用 已经变得突出，而single-spa仍然是团队想要基于生命周期的应用程序注册的orchestration选项。
例如，checkout团队可能会发布一个支付流程修正，而不需要重建目录片段。目录团队可以继续使用较慢的发布频率，因为壳会根据其运行时配置加载每个批准的片段。这种独立的交付边界，而不是可视化的分离组件的外观，是架构的主要收益。
评估周围平台的团队也需要考虑 前端系统的应用程序基础设施因为仓库和框架本身无法提供可靠的组合。
比较核心微前端模式
微前端问题没有一个单一的集成机制可以解决所有问题。选择微前端模式时，应根据隔离、通信、依赖共享、浏览器行为和运维所有权等因素进行比较，而不是选择最时尚的工具。
| 模式 | 隔离 | context | Page/area: Capgo Builder / native cloud build product page. Role: Short UI label or navigation item. Seen in: page native-build.astro. Message key `native_build_v2_trust_iso_lbl` (Native Build V2 Trust Iso Lbl). | 集成模型 | 共享依赖 |
|---|---|---|---|---|---|
| 性能 | context | Page/area: Homepage problem/solution section. Role: Section or page heading. Seen in: page premium-support.astro. Message key `ps_help_performance_title` (Ps Help Performance Title). | 最佳匹配项 | Can add loading and communication overhead | Untrusted, legacy, or highly isolated experiences |
| Web 组件 | 封装的元素和，使用时，Shadow DOM 样式 | 由 shell 挂载的自定义元素 | 共享的设计令牌和浏览器 API | 通常可预测，但取决于组件大小 | 需要框架灵活性的标准化团队 |
| 模块联邦 | 中等运行时隔离 | 在运行时加载和挂载远程模块 | 显式协商或捆绑依赖项 | 在加载和去重复控制的情况下，效率很高 | 独立发布的紧密集成应用 |
| single-spa | 边界是协调而不是完整的隔离模型 | 通过生命周期钩子注册的应用 | 取决于应用和根配置 | 取决于加载规则和框架组合 | 基于路由激活的多框架协调 |
Iframes
在比较中，iframe提供了最强的边界。嵌入式应用有自己的文档、样式和 JavaScript 环境，因此不会意外地改变宿主页面的 DOM。跨窗口消息可以创建一个受控的通信路径。
这种隔离使 iframe 对遗留系统、合作伙伴体验或必须保持独立的内容非常有用。成本出现在响应式布局、导航、可访问性、焦点管理和共享身份验证中。如果宿主和嵌入式应用不小心协调，checkout iframe 可能会感觉像一个外国表面。
Web 组件
Web 组件使用浏览器标准，而不是要求每个团队采用相同的框架。自定义元素定义了一个稳定的挂载表面，Shadow DOM 可以限制样式泄露。shell 还需要处理应用程序路由、加载状态、错误边界和共享设计令牌。
当团队想要在不使浏览器加载整个应用程序运行时的每个片段的框架灵活性时，这个选项很好用。它并没有自动解决依赖大小、状态通信或治理的问题。自定义元素仍然可以包含一个拥有自己的运营复杂性的大型应用程序。
模块联邦
模块联邦（Module Federation）是 Webpack 5 引入并由工具如 Vite 和 Rspack 支持的技术，它在运行时从远程入口加载编译好的模块。它提供了紧密的集成，使共享组件和协调导航感觉更加自然，通常与 iframe 相比更自然。
这种便利性带来了责任。团队需要兼容的公开接口、共享依赖项的规则、远程版本处理和一个当一个远程无法加载时的恢复计划。 单体和微服务架构之间的区别 提供了有用的上下文来分离部署独立性和简单的code分解。
单应用
single-spa 作为一个框架无关的协调者。团队注册应用程序和生命周期钩子，根配置根据路由或其他条件激活它们。它可以协调使用不同框架构建的应用程序，但它并不消除对契约、依赖性政策、性能预算或安全控制的需求。
团队可以组合这些机制。例如，single-spa 的根可能协调路由，Module Federation 可能提供远程模块，web 组件可能定义公共挂载表面。这种组合可以很强大，但每增加一个层次，开发者必须理解和测试的行为就多了。
利弊和隐含风险
微前端将决策推向边界。它们可以减少发布的爆炸半径并给团队更多控制，但系统必须管理更多的艺术品、契约和运行时条件。
| 维度 | 利益 | 利弊/隐含风险 |
|---|---|---|
| 团队自主权 | 团队拥有从头到尾的商业切片 | 团队必须维护单独的管道、on-call 负责人和发布纪律 |
| 部署 | 一个片段可以不重建整个界面就发布 | 发布版本变得非原子化，因此生产环境中可能会出现不兼容的版本 |
| 故障隔离 | 远程失败可以通过fallback进行包含 | 错误边界差劲，仍然可能使导航或关键旅程不可用 |
| 性能 | 上下文: 首页问题/解决方案部分。角色: 部分或页面标题。见于: 页面premium-support.astro。消息键`ps_help_performance_title` (Ps Help Performance Title)。 | More requests, duplicated framework code, and remote initialization can hurt runtime performance |
| 更多请求，重复的框架__CAPGO_KEEP_0__和远程初始化可能会损害运行时性能 | 技术选择 | 团队可以在允许的边界内使用不同的框架 |
| 调试、可访问性、设计一致性和招聘变得更加困难 | 安全性上下文: 企业产品/定价页面。角色: UI标签。见于: 页面enterprise.astro。消息键`enterprise_hero_security_label` (Enterprise Hero Security Label)。 | The shell可能执行它没有充分验证的远程code |
| 治理 | 共享标准可以保留一致的产品 | 设计系统、依赖规则、合同和平台支持需要持续的协调 |
性能账单
独立片通常会产生单独构建的资产。没有细心的加载规则，浏览器可能会请求更多的文件，初始化更多code，或者下载重复的框架依赖项。微前端的性能指导强调按需加载、谨慎依赖共享、模块级缓存和故障隔离
实用的设计从现有应用程序的基线开始。测量路由启动、捆绑组合、远程加载、初始化和用户可见的故障。然后为壳和每个高流量片设置预算。懒加载只有在应用程序不阻塞关键旅程时才会有帮助，关键旅程是长链条上的远程模块
安全性
远程模块不是因为它有一个单独的仓库而自动安全。壳可能执行它没有验证的code，前端边界不能代替API或令牌服务的授权 安全性 highlights why trust, signing, integrity checks, and authorization need design attention before teams distribute runtime code.
安全性关注的微前端分析突出了为什么信任、签名、完整性检查和授权需要在团队分发运行时__CAPGO_KEEP_0__之前进行设计注意事项 Nx的架构指导 确定协调、环境配置、应用效率和可重用性作为持续挑战。
架构并不会消除协调。它将协调从发布会议转变为合同、自动化、可观察性和治理。
团队还需要对共享依赖项、可访问性审查、事件响应和回滚决策拥有明确的所有权。如果没有人拥有平台层，每个产品团队都会以不同的方式解决组合，用户将经历的结果一致性会被视为一个破碎的应用。
测试部署和迁移实践
测试必须反映应用程序的运行方式。一个通过单元测试的片段仍然可能在壳提供了一个改变的路由、一个意外的身份验证状态或一个不同的共享依赖项时失败。
构建层次化的测试系统
从每个片段的孤立测试开始。这些测试验证渲染、商业规则、键盘行为、加载状态和本地错误处理，且不需要完整的壳。
合同测试位于它们之上。它们验证壳和片段之间的接口，包括挂载输入、路由模式、发射事件、期望载荷、身份验证假设和fallback行为。合同测试应该在生产之前失败，如果一个团队改变了另一个团队消费的接口。
shell集成测试然后加载真实的片段艺术品在一个代表性的组合中。它们应该涵盖路由、身份验证转换、共享导航、加载失败和版本 combination。端到端测试属于顶部，因为它们验证完整的旅程，如浏览产品、登录和完成结算跨多个独立交付的片段。
控制发布面板
使用带有版本号的清单，让shell可以识别它加载的确切片段艺术品。清单还给运营人员提供了一个地方来固定一个已知的好版本，当远程发布引起错误时。
有用的控制项包括：
- 功能标志： 激活一个新片段给内部人员或选择的路线之前广泛曝光。
- 金丝雀发布： 将有限的观众导向新艺术品，同时监测浏览器错误、加载失败和关键业务动作。
- 可观察的捆绑包： 将发布标识符添加到日志、跟踪和客户端错误中，以便负责的团队可以识别失败的片段。
- 回滚路径： 保持兼容的先前 artifact 可用，并将回滚设置为一个可操作的动作，而不是手动重建。
团队应该在一个模拟生产环境中测试 shell 和 fragment。成功的本地运行并不能证明内容交付路径、缓存、身份验证令牌或远程清单会正确地为用户工作。 部署自动化实践 可以支持可重复的推广和回滚工作流程，但架构仍然需要明确的所有权。
逐步迁移一个域名
迁移路由器迁移一个功能从 monolith 到一个新的 fragment，其他部分保持不变。一个特性开关可以支持并行运行，允许团队在新路径与现有实现之间进行比较，然后将新路由设置为默认。
考虑一个商业应用程序，分离的目录、账户和结账团队。shell 拥有导航和身份验证，目录团队拥有产品浏览，账户团队拥有配置文件设置，结账团队拥有购物车和支付流程。每个团队都发布自己的 artifact，而合同测试保护路由和事件协议。
从一个低风险的域名开始，发布它后面一个标志，并通过真实的旅程观察它。扩展只有当团队可以部署、诊断和回滚该片段而不需要整个组织协调一个发布时才可以。
在 Capacitor 和 Electron 中使用微前端
A Capacitor 或 Electron 应用程序在浏览器 shell 周围添加了另一个 shell。 Capacitor 将 web code 放置在一个本机 WebView 中，而 Electron 将 web code 在桌面渲染器进程中运行。在两种情况下，应用程序都可以加载一个本地 shell，该 shell 可以在运行时从本地文件系统中获取所选的前端 artifact，而不是将每个界面更改嵌入到本机二进制文件中。
这种安排创建了一个有用的发布分离。 本机能力、权限和桥接 code 与安装的应用程序绑定在一起，而 web 所有权的表面，如账户、帮助、目录或设置，可以独立于应用程序的发布路径。 shell 还需要决定哪些碎片来自哪里、哪个版本是批准的，以及如果 fetch 或验证步骤失败时应用程序应该做什么。
实时更新和回滚
实时更新系统必须将前端 artifact 视为可发布的软件。它应该交付 签名包并在激活之前验证它们，支持阶段性发布的发布渠道，在下一次启动时应用更新，而不是中断活动会话，并提供自动回滚保护，具有原子重置。
这些控制映射到微前端交付。 移动或桌面 shell 可以固定清单，获取兼容碎片，验证其签名，并在完整包可用时激活它。如果下一次启动检测到失败，更新器可以恢复到以前的已知良好状态，而不是留下用户使用部分更新的界面。
Capgo 是一种实现此交付模型的选项。它为 CapacitorJS 和 Electron 应用程序提供了一个实时更新平台，发布了签名的 Web 包，支持目标渠道，应用下一次启动时更新，并提供日志，版本历史，采用率和失败指标，回滚保护，CI/CD 集成，以及一个 API。 团队考虑使用原生桥接时，还应了解 Capacitor 如何连接 Web 和原生 code。.
原生壳中的变化
原生壳引入的约束可能使浏览器应用程序无法面对:
- 连接性: 当设备脱机时，可能会出现碎片不可用，因此壳需要缓存的艺术品或本地fallback。
- 兼容性: Web 包可能依赖于原生桥接行为，但安装的二进制文件不支持。
- 安全性: 远程 code 必须在应用程序上下文中进行身份验证，完整性检查和授权。
- 恢复: 必须让 shell 能够拒绝无效的包并恢复一个工作的版本而不需要立即的存储分发。
- 会话安全性： 在支付或表单流程中更新可能会导致不一致的状态，因此下次启动激活比中断活动工作更安全。
这个模型加强了回滚功能，当交付平台提供原子激活和详细的发布指标时。它会使架构更加复杂，当团队认为 web 独立性消除了原生兼容性规划的需求时。原生 shell 仍然是一个合同边界，每个片段都必须尊重它。
何时选择微前端
选择微前端时 独立部署是一个真实的需求,多个小组拥有明确分离的产品表面，或者遗留和新接口必须在长期迁移期间共存。技术多样性也可以证明模式的必要性，当团队需要框架边界而单个构建无法清洁地适应时。
避免它，当一个小团队可以舒适地拥有一个前端，域共享广泛的可变状态，或者您的组织缺乏可靠的 CI、可观察性、合同测试和回滚程序时。一个分布式接口没有这些基础并不创造自治。它创造了更多的失败地点。
使用一个简单的起始测试：
- 所有权： 一个团队是否可以为提议的片段做出决定？
- 边界： shell 和 slice 是否可以通过稳定的契约进行通信？
- 发布需求： 团队是否需要独立部署？
- 运维就绪： 是否可以监控、测试、固定和回滚片段？
- 用户价值： 是否可以通过拆分提高交付速度而不损害性能或一致性？
首先选择一个风险较低的区域，如帮助内容或设置。定义挂载契约、路由所有权、事件、设计令牌、fallback 行为和版本策略。通过特性标志发布，测量添加的包和加载成本，并记录每个新渠道、清单、依赖规则和回滚路径。
微前端是一种工具，用于实现组织和发布的独立性，而不是自动提高前端质量。如果发布问题较小，模块化的单体可能是更好的答案。如果协调问题较大且持久，经过精心管理的微前端架构可以给团队提供所需的自主权。
如果您正在评估微前端用于 Capacitor 或 Electron 产品 Capgo 可以帮助您通过受控的通道分发签名的Web包，激活下一次启动的更新，并通过回滚保护恢复。请访问Capgo，查看其分发、可观察性和API选项，了解如何设计您的碎片发布流程。
