微前端全景指南：核心概念、适用场景、六大方案对比与 24 道面试题

微前端适合解决大型前端系统中的团队协作、独立发布和渐进式迁移问题。它把业务拆分为能够独立交付的应用，再通过明确的运行协议组合为统一产品。采用之前，首先要判断业务边界和团队边界是否清晰，而不是先选择一个微前端框架。

本文从概念与场景出发，梳理一个完善方案应具备的能力，比较 single-spa、qiankun、micro-app、无界 Wujie、Module Federation 和 iframe，最后给出 24 道分类面试题及参考答案。框架细节以 qiankun 2.x、micro-app 1.x、Wujie 2.x 和 Webpack 5 的模块联邦为参照；资料核对日期为 2026 年 10 月 31 日。选型建议是基于机制的工程判断，不代表官方排名。

一、微前端是什么

微前端是一种组织和交付前端应用的架构方式：按照业务领域将大型系统拆分为多个自治应用，各应用拥有相对独立的开发、构建、测试和发布流程，再通过路由、页面容器或模块加载机制组合运行。

例如，一个企业平台可以由订单、库存、财务三个团队分别维护对应应用。主应用提供统一导航和用户上下文，各团队在约定的接口范围内独立发布。是否真的独立，取决于发布流程和兼容性契约；仅把代码搬到多个目录，并不会自动得到这些能力。

多个技术栈共存是一种可选能力。全部使用 React 的团队同样可能需要微前端；只有一个小团队维护的 React 与 Vue 混合页面，也未必值得建立完整的微前端平台。

二、哪些场景适合使用

• 多团队维护大型业务平台订单、营销、财务等业务有独立负责人和发布节奏，单体应用的统一发版已经成为协作瓶颈。
• 整合历史系统希望将已有业务纳入统一入口，同时逐步处理登录、导航和视觉一致性，避免一次性重写所有系统。
• 渐进式技术迁移以业务页面为单位替换旧框架、旧构建链或旧架构，让新旧应用在一段时间内共存。
• 明确边界的业务扩展多个业务模块由不同团队独立交付，需要按权限或产品配置组合加载；同时对模块来源与版本有治理能力。

不适合的典型情况包括：单个小团队维护的简单产品；业务间大量共享即时状态、很难确定所有权；主要问题只是组件复用不足或目录混乱。此时先做模块化、依赖梳理、组件设计或构建优化，往往更直接。

拆分时优先选择订单、结算、库存这样的业务边界。按钮、表格和弹窗更适合作为组件。如果一个日常需求总要修改三个子应用并要求它们同时上线，应重新检查拆分边界，而不是继续增加通信机制。

三、一个完善的微前端方案应该具备哪些能力

这里需要区分运行时框架和完整工程方案：框架应提供加载、生命周期、隔离等基础能力及扩展接口；CI/CD、身份体系、业务监控和组织规范通常由团队的平台体系完成。不能要求一个浏览器运行库独自承担所有职责。

隔离不能只看全局变量。子应用卸载时，还要考虑 React 根节点、定时器、事件监听、订阅、Observer、WebSocket 和请求回调。缓存模块不等于缓存 UI 实例，保留 DOM 也不等于已经正确暂停业务副作用。

四、使用微前端有什么收益与成本

这些收益不是安装一个依赖就能获得的。可以持续观察发布等待时间、跨团队联动发布次数、故障恢复时间、首屏与切换耗时、重复资源体积和内存占用，判断架构是否带来了净收益。不要把“独立部署”直接等同于“故障完全隔离”，也不要把微前端当成自动的性能优化方案。

五、六种主流方案的优缺点对比

下面同时比较应用编排框架、模块加载机制和浏览器原生容器。它们处于不同层次，因此部分方案可以组合使用；选择时应先明确要解决的是整应用接入、远程模块复用，还是独立文档嵌入。

single-spa 与 qiankun：从编排基础到整应用接入

single-spa 的重点是应用如何激活、挂载和卸载，适合构建自定义应用编排层。qiankun 2.x 在其基础上提供 HTML 入口、沙箱、样式隔离和预加载等能力，减少整应用接入时的重复工作。qiankun 通常仍要求子应用暴露生命周期，并正确处理资源路径和构建输出。

micro-app：组件式入口不等于所有环境天然隔离

micro-app 通过自定义元素承载子应用，并提供虚拟路由、通信和沙箱能力。默认样式隔离通过给选择器添加应用作用域前缀实现，主应用的全局样式仍可能进入子应用。JS 沙箱和 iframe 沙箱也有不同适配要求，不能把“类 Web Components 使用方式”直接理解为所有配置都采用原生 Shadow DOM。

Wujie：JS 环境和页面容器分离

Wujie 的典型模式让子应用 JS 在 iframe 中运行，DOM 在主文档的 Web Components 容器中展示，通过代理连接相关操作。这与直接显示一个完整 iframe 页面不同。它提供多种运行模式，但复杂弹层、DOM 操作、事件行为以及第三方库仍应按实际使用方式验证。框架使用的同源 iframe 也不能直接作为恶意代码的安全边界。

Module Federation：远程模块共享需要版本治理

Webpack 5 模块联邦通过远程容器暴露模块，宿主在运行时获取模块工厂并执行；共享作用域用于协调公共依赖。远端既可以暴露一个组件，也可以暴露返回销毁函数的应用挂载方法。它适合更细粒度的组合，但默认不隔离全局变量和 CSS。共享 React 时还需协调渲染器、版本范围和单例配置，singleton 不是版本兼容性的保证。

iframe：独立文档带来清晰边界，也带来融合成本

iframe 提供独立的浏览上下文和文档，适合低交互耦合的完整页面。通信可以使用 postMessage，但应校验来源和消息格式。若要运行不可信内容，还需结合跨源部署和最小化 sandbox 权限；同源、宽权限配置的 iframe 不意味着绝对安全。页面内普通浮层也不能自然越过 iframe 的文档视口。

选型建议

• 整合多个已有业务系统优先评估 qiankun、micro-app、Wujie，重点做资源、路由、弹层、监听器和卸载验证。
• 共享组件和业务模块重点评估 Module Federation，同时建立版本与契约治理。
• 需要自定义平台基础设施可基于 single-spa 组合加载、隔离、通信与部署能力。
• 嵌入低耦合完整页面iframe 往往已经足够，按实际跨窗口需求补齐通信和导航。

六、同一个主应用能同时使用多种方案吗

可以，但要区分“运行时按应用选择引擎”和“同一页面同时展示多个引擎的应用”。前者可以由侧边栏决定当前应用，后者还要处理多个活跃实例的路由、样式和运行环境交互。即使每次只展示一个应用，之前初始化过的引擎也可能保留全局补丁，不能仅靠容器不同就认定互不影响。

single-spa 与 Module Federation 是不同层次的组合，官方文档明确说明可以配合使用。多个完整微前端引擎混用则需要针对具体版本验证，不应把各框架的“支持多应用”视为跨框架兼容承诺。

一种可行的设计是：主应用统一管理菜单和路由；注册表给每个应用标注 engine；各适配器只负责自己的初始化、挂载和卸载。每个实例由一个引擎管理，使用独立容器，公共通信由主应用的协议转接。

type EngineName = 'qiankun' | 'micro-app' | 'wujie' | 'federation';

interface MicroEngine {
  initialize(): void;
  mount(options: {
    name: string;
    entry: string;
    container: HTMLElement;
    signal: AbortSignal;
  }): {
    ready: Promise<unknown>;
    dispose(): Promise<unknown>;
  };
}

// 配置示意：省略实际地址、错误处理与调度实现。
const applications = [
  { name: 'order', engine: 'qiankun' },
  { name: 'report', engine: 'micro-app' },
  { name: 'workspace', engine: 'wujie' },
  { name: 'analytics', engine: 'federation' },
];

统一接口能减少业务代码对引擎的依赖，但不能抹平路由、保活、通信和资源加载规则的差异。切换流程还需要处理异步取消、旧实例清理、迟到结果和错误恢复。把所有任务串成一个队列时，应避免单个永不结束的加载阻塞整个工作台。

七、面试题与参考答案

以下 24 道题按六个主题组织。回答时先说明目标，再解释实现机制，最后给出适用条件、局限与验证方式。涉及项目经历时，只使用自己实际做过和测量过的内容。

A. 基础概念与边界

1. 微前端的核心价值是什么？

核心是业务应用和团队能够在明确契约下独立交付，并支持渐进式迁移。技术栈混用只是可选能力。独立仓库不必然意味着独立发布，如果每次仍需要多个团队同步上线，自治收益就很有限。

2. 如何判断一个项目是否需要微前端？

观察协作和发布瓶颈是否真实存在，业务是否能划分为相对独立的领域，以及团队是否有能力承担额外治理。小团队、简单页面或共享状态高度密集的系统，应先尝试模块化和组件化。

3. 子应用边界应该怎样划分？

优先按业务领域、负责人和发布节奏划分，例如订单、库存、财务。衡量边界是否合理，可以看常规需求跨应用修改次数和联动发布频率。UI 组件级复用通常交给组件库或模块共享机制。

4. 微前端与 Monorepo 是否冲突？

不冲突。Monorepo 是源码与工具链组织方式，微前端是应用交付与组合方式。同仓库可以通过构建任务和发布流水线实现独立交付；多仓库也可能因为契约强耦合而无法独立发布。

B. 加载机制与生命周期

5. HTML Entry 的基本加载流程是什么？

从 HTML 入口发现结构、脚本和样式，解析资源地址并加载，在框架安排的环境中执行脚本，取得生命周期或触发应用渲染，再将内容挂到指定容器。入口 HTML 成功不意味着分包地址、CORS 和脚本执行顺序都正确。

6. bootstrap、mount、unmount 分别负责什么？

bootstrap 处理应用实例的一次性初始化；mount 建立当前 UI 和必要订阅；unmount 释放根节点与副作用。缓存代码后再次进入通常仍会重新 mount。不要把删除容器 DOM 当成完整卸载，定时器、监听器和连接也需要释放。

7. qiankun 的 registerMicroApps 与 loadMicroApp 有何区别？

registerMicroApps 配合 start，依据激活规则随 URL 变化调度应用；loadMicroApp 由调用方手动决定挂载和卸载，适合组件容器或已经由 React Router 管理页面的场景。同一个实例应有唯一的生命周期管理者。

8. 为什么接入后图片或懒加载 chunk 请求失败？

先检查失败请求最终落在哪个域名和路径，再检查构建 publicPath、入口基础路径、动态资源插入和 CORS。入口地址与运行时分包地址是两个问题。还要确认服务器没有把缺失的 JS 请求回退成 HTML。

C. 隔离与副作用

9. Proxy 沙箱的基本原理是什么？

通过代理对象拦截全局属性读写，并让代码执行时的全局访问尽量经过代理，将部分修改留在子应用自己的状态中。但全局对象的嵌套引用、原型修改、DOM 和事件等并不会因此自动全部隔离，需要额外约束与处理。

10. CSS Modules、选择器前缀与 Shadow DOM 有什么差别？

CSS Modules 降低类名冲突；选择器前缀限制子应用样式的匹配范围；Shadow DOM 提供样式封装边界。前两者仍要关注宿主全局选择器，Shadow DOM 则要考虑继承、样式注入、弹层和事件语义。应根据实际组件生态选择。

11. 子应用中的 Modal、Dropdown 为什么容易样式异常？

组件常通过 Portal 把弹层挂到 body，实际节点可能离开子应用的样式作用域。应检查最终 DOM 所在位置、样式注入位置、层叠上下文和 overflow，再通过组件容器配置协调挂载；把所有弹层强行塞回容器也可能产生裁剪。

12. 微前端沙箱能否安全运行不可信代码？

普通同页面沙箱主要用于减少兼容性干扰，不应直接作为恶意代码的安全边界。不可信内容需要另行设计跨源容器、最小权限和通信校验。同源 iframe 和宽权限 sandbox 配置也不等同于安全隔离。

D. 路由、通信与权限

13. 主子应用路由应如何协作？

先定义主应用负责的路径与子应用内部路径。共享浏览器路径时，子应用通常需要正确的 basename；虚拟路由则有自己的同步规则。例如 micro-app 的 search 模式将子路由同步到查询参数，pure 模式不将其同步到浏览器地址。不能跨模式照抄配置。

14. 为什么前端跳转正常，刷新深层路径却 404？

页面内跳转由前端路由处理，刷新会向服务器请求该路径。服务器需要为页面请求提供正确的 SPA 回退，同时保留 JS、CSS 等缺失资源的真实错误响应。还要检查主应用和独立子应用各自的部署基路径。

15. 主子应用通信应该如何选择？

明确的父子关系适合 props 与回调；松耦合通知可使用有命名和载荷约定的事件；可分享导航状态适合放在 URL；跨窗口通信可用 postMessage。业务状态优先保留在拥有它的应用内，订阅必须可清理，协议变更需要兼容策略。

16. 统一登录与权限如何设计？

身份系统提供登录能力，主应用组织用户上下文和导航权限，子应用处理自己的页面与操作展示。服务端必须校验请求权限。凭据采用 Cookie、BFF 或令牌机制取决于部署与安全设计，还要覆盖过期、退出和多应用状态同步。

E. 性能、依赖与发布

17. 多个应用都使用 React，是否一定要共享一份？

不一定。各应用独立根节点和独立依赖可以保留升级自主权；共享能减少重复下载，但会引入版本约束。跨应用传递 React 组件时尤其要确认 React 与渲染器实例兼容。是否共享应同时考虑交互方式、资源收益和维护成本。

18. 模块联邦出现 Invalid hook call 应如何排查？

检查 Hooks 使用规则、重复 React 实例、React 与渲染器版本，以及宿主和远端的 shared 配置。验证实际加载的版本与来源，而不只看配置文件。singleton 控制共享实例选择，不能让不兼容版本自动兼容。

19. 微前端首屏和切换慢，如何优化？

先拆分入口请求、资源下载、JS 执行、挂载、业务数据请求和页面可用时间，再针对瓶颈处理。常见措施包括按需加载、适量预加载、缓存、压缩和依赖治理。保活可降低重复初始化，却会增加内存与后台副作用，必须测量后选择。

20. 独立发布怎样避免旧页面的 chunk 404？

采用内容哈希资源，先上传完整产物，再切换入口或版本清单。入口使用合理的重新验证策略，旧资源保留足够时间并支持回滚。共享依赖和通信协议也需保持兼容，否则资源部署成功仍可能造成运行错误。

F. 工程排障与架构设计

21. 快速切换应用时怎样避免重复挂载？

为每次加载建立实例标识或取消信号，离开时立即标记失效，禁止迟到结果挂载。协调同名实例的挂载与卸载顺序，清理旧根节点和副作用。需要测试连续切换、加载途中离开、重试与卸载失败，而不仅测试正常路径。

22. React 错误边界能兜住所有子应用错误吗？

不能。它主要覆盖其 React 树内特定的渲染和生命周期错误，不能自动捕获所有事件、异步 Promise 或独立 React 根中的异常。主应用还应处理资源加载、挂载拒绝和通信错误，并在日志中带上应用、版本与阶段。

23. 预加载、预执行和保活有什么区别？

预加载通常提前获取资源；预执行可能提前执行应用代码并产生副作用；保活是在切走后保留实例或状态。这三种策略作用于不同阶段，对带宽、CPU、内存和后台活动的影响不同，不能统一理解为缓存。

24. 如何设计同一主应用接入多种微前端引擎？

将公共布局、菜单、身份上下文和业务协议放在主应用，注册表标注每个应用的引擎，适配器提供统一挂载与销毁接口。每个实例由一个引擎负责，动态加载对应适配器。还必须验证全局补丁、路由、样式、共享依赖和快速切换时的交互，统一接口不代表底层行为一致。

八、落地时如何验证

建议先选择一个边界清晰的真实业务作为试点。建立接入清单，记录资源入口、路由模式、样式策略、通信契约、卸载责任与发布地址，然后用验证结果决定是否扩大范围。

• 运行行为验证首次加载、切换、重复进入、刷新、前进后退、深层链接与登录过期。
• 异常与恢复验证服务不可达、资源 404、挂载异常、超时取消、重试、灰度与回滚。
• 兼容性验证弹层、动态样式、第三方 SDK、多个引擎初始化顺序及卸载后的全局影响。
• 性能与可观测性同时观察首屏、切换耗时、内存、监听器数量和带应用版本的错误日志。
• 验证范围构建、类型检查、单元测试和 HTTP 检查各有作用；实际浏览器中的路由、样式和引擎共存行为还需集成测试。