微前端是什么？什么时候值得用，什么时候只是增加复杂度？

知识点详解：应用独立之后，哪些责任必须有人接住

先确定为什么要独立交付

假设一个管理平台由三个团队负责：客户管理、报表和配置。它们发布节奏不同，升级技术栈也不同，希望单个团队不必每次等全平台一起构建和上线。

这时，独立应用边界可能有价值。只是代码文件变多，或者页面数量变多，并不能直接证明要上微前端。

Monorepo、普通模块包和微前端也不是同一维度：仓库怎么组织，代码怎么复用，应用怎么运行与发布，可以分别选择。一个仓库里可以有多个独立应用，也可以有一个统一发布的应用。

组合方式不同，隔离也不同

single-spa 这类方案组织应用的加载、挂载和卸载；Module Federation 提供跨独立构建共享和消费模块的机制。它们可以成为实现手段，但不自动补齐产品级所有治理。

iframe 给出单独的浏览上下文，配合不同来源、sandbox 和明确通信协议，可以获得不同于同页面模块的隔离方式。不过登录、跳转、尺寸、无障碍和通信都要额外处理。

同一个页面里共享 JavaScript 环境的模块，不是因为叫“子应用”就天然变成安全沙箱。CSS 命名或样式隔离，也不能替代权限与安全边界。

这些是浏览器与 JavaScript 集成机制，没有同一套 Python 子应用 API；本文不做机械翻译。

共享依赖和状态，要有版本与归属

两个子应用共享 React 或组件库，可以减少重复下载，但必须约定兼容版本和共享策略。Module Federation 的 shared 配置涉及版本选择，不能把 singleton 当成“任何版本都一定兼容”。

登录身份通常需要统一入口与后端权限共同处理，不能只靠共享一个前端变量。业务状态也不要变成所有子应用都能随意修改的全局对象。

通信最好围绕明确事件或接口，并约定数据格式与版本。拆开后仍然互相读取内部 store，团队只是把耦合从编译时搬到了运行时。

真正验收的是组合后的失败路径

子应用加载失败时，入口是否还能打开其他功能？某个团队回滚后，是否兼容当前外壳和其他应用？这些问题比“成功挂载了一次”更重要。

需要管理路由范围、资源路径、样式清理和应用卸载。还要统一必要的监控、可访问性与用户体验，避免每个子应用都是一套不同产品。

如果独立发布的收益小于这些维护成本，就先使用边界清楚的模块化单体前端。微前端是组织与交付方案，不是项目成熟度的徽章。

本题机制参考：single-spa：Recommended Setup、Webpack：Module Federation、MDN：iframe。

面试官继续追问

Module Federation 就是微前端吗？

它是跨构建共享模块的机制，可以服务微前端，也可以用于共享组件等其他场景，不能等同。

子应用独立发布，就不用协调版本了吗？

更需要明确兼容契约、共享依赖和回滚策略。独立交付不是独立于产品责任。

微前端一定要多技术栈吗？

不一定。同技术栈也可以按团队与发布边界拆分，多技术栈只是可能需求之一。

面试速记卡

• 目标：明确边界与独立交付，再可靠组合。
• 手段：生命周期编排、模块联邦、iframe各有取舍。
• 隔离：应用命名不是安全沙箱，样式隔离不等于权限隔离。
• 契约：路由、依赖版本、通信与状态归属。
• 选型：独立演进收益，要覆盖集成和故障治理成本。