01

60 秒回答模板

微前端是把一个大型前端系统按业务域或团队边界拆成多个可独立开发、构建、发布的子应用，由主应用统一负责路由分发、资源加载、生命周期调用和全局能力接入。典型实现是主应用注册子应用信息，路由命中后加载子应用的 JS/CSS，执行 bootstrap、mount、unmount 等生命周期；同时要处理样式隔离、JS 沙箱、应用间通信、公共依赖、权限和异常兜底。它解决的是多团队协作和渐进式改造问题，不是天然性能优化方案，收益要和运行时复杂度、调试成本、依赖版本治理一起评估。

考点 核心机制与工程取舍
难度 中高频面试题
回答目标 按定义、机制、场景讲清楚
02

深入解析

01

先讲使用动机

微前端适合巨型单体前端、多团队并行交付、老系统渐进迁移、多技术栈共存和独立发布诉求。它不是为了把页面拆小而拆，而是为了让业务边界、团队边界和发布边界更清晰。

02

主应用和子应用分工

主应用负责路由匹配、菜单权限、登录态、全局布局、运行时注册表、资源加载和错误兜底。子应用负责自己的页面、路由片段、状态和构建产物，并暴露主应用约定的挂载与卸载生命周期。

03

资源加载和生命周期

常见流程是注册子应用入口、监听路由变化、拉取 HTML 或 manifest、解析 JS/CSS、执行 bootstrap 初始化，再在容器节点上 mount。离开路由时调用 unmount，清理事件监听、定时器、全局状态和 DOM，避免内存泄漏。

04

隔离是实现难点

样式隔离可以用命名前缀、CSS Modules、Shadow DOM 或运行时样式作用域。JS 隔离通常依赖 Proxy 沙箱、快照沙箱或 iframe，但要权衡兼容性、性能和第三方库对 window、document 的修改。

05

通信和依赖治理

通信不要做成随意的全局变量共享，常见方式有 props 注入、事件总线、URL 状态、统一 store 或服务层协议。公共依赖要明确共享版本、降级策略和重复打包成本，否则不同子应用的 React/Vue、组件库版本会互相牵制。

06

最后补工程边界

微前端会带来运行时调试、灰度发布、监控归因、首屏资源、权限一致性和跨应用体验一致性的成本。答题时要强调它是组织和工程架构方案，不能把所有性能或代码复用问题都归给微前端解决。

03

易错点

  • 把微前端说成组件库或 iframe 嵌页面，没有讲主子应用生命周期和独立部署。
  • 只说可以技术栈无关，不讲样式隔离、JS 沙箱和全局副作用清理。
  • 默认微前端一定提升性能，忽略运行时框架和重复依赖成本。
  • 通信方案只说 event bus，没有说明数据所有权、协议边界和卸载清理。
04

面试官追问

iframe 微前端和运行时沙箱有什么区别？

iframe 隔离最强，天然隔离 JS、CSS 和全局环境，但通信、路由、弹窗、性能和体验整合成本高。运行时沙箱体验更像单页应用，集成更顺滑，但隔离不如 iframe 彻底，需要自己处理全局污染和样式冲突。

子应用卸载时最容易漏什么？

容易漏全局事件、定时器、未取消请求、订阅、弹窗节点、全局 store 状态和第三方库挂到 window 上的副作用。unmount 要把这些资源逐项清理。

微前端如何做应用间通信？

优先用明确协议：主应用 props 注入、URL 参数、事件总线、跨应用服务或共享 store。关键是定义数据所有权和生命周期，避免任意子应用互相读写内部状态。

微前端一定能提升首屏性能吗？

不一定。拆分后可能减少单次加载体积，也可能因为运行时框架、重复依赖和多个子应用资源导致更慢。性能要靠按需加载、依赖共享、缓存和首屏链路优化验证。