标准答案
- 微前端适合多个业务团队长期维护同一个大系统，但需要独立发布和技术边界的场景。
- 它能把应用拆成主应用和子应用，降低单个仓库、单条流水线和单次发布的耦合。
- 常见方案包括 iframe、single-spa/qiankun、Module Federation、Web Components 等。
- 代价包括运行时加载复杂、公共依赖重复、样式污染、全局变量冲突、路由和权限协调复杂。
- 如果只是页面数量多或想提高性能，微前端不一定是最小成本方案。
题目解析
微前端首先是组织和发布边界方案。一个后台系统如果由多个团队共同开发，所有模块都绑在同一次构建、同一次发布里，协作成本会越来越高，微前端可以把责任和发布节奏拆开。
它不是免费拆分。主应用要负责注册、加载、路由、权限、通信和错误兜底；子应用要处理样式作用域、依赖版本、生命周期和独立部署。线上问题也会从“一个应用坏了”变成“主子应用交界处哪里坏了”。
面试里不要把微前端讲成万能架构。更好的判断是：团队规模、发布独立性、技术栈历史包袱和治理能力是否真的需要它。
代码示例
微前端常见结构是主应用负责壳和治理，子应用负责业务域。
Text
shell app:
auth, layout, menu, route registry, error boundary
micro apps:
order app
finance app
user app
shared contracts:
routing, events, permissions, design tokens常见误区
- 把微前端当成性能优化手段，忽略它主要解决的是组织和发布耦合。
- 没有统一依赖、样式、权限和通信约定，拆完后运行时冲突更多。
- 小团队小系统过早引入微前端，复杂度超过收益。