微前端是什么
微前端按业务域把前端拆成可独立构建、独立发布的应用，由不同团队分别负责，最后集成为统一入口。它解决的核心问题是团队交付边界：一个巨型前端里所有人共用一个发布流水线，改动互相阻塞。集成方式包括构建时依赖、运行时模块加载、iframe 与 Web Components，各自在隔离性、性能与一致性上取舍不同；如果前端规模不大，统一应用内部做模块化通常更划算。
基本信息
| 拆分依据 | 按业务域划分，不要按技术层或页面类型划分 |
|---|---|
| 集成方式 | 构建时依赖、运行时模块加载、iframe、Web Components |
| 共享约定 | 路由归属、公共依赖版本、登录态与埋点规范 |
| 发布方式 | 各子应用独立发布，宿主提供路由与布局壳 |
| 前提条件 | 多团队并行开发、发布节奏确实互相阻塞时才值得拆分 |
典型使用场景
- 多团队并行：各业务域团队按自己的节奏发布，不再排队等主应用
- 存量系统渐进改造：新页面按新框架开发，旧页面逐步替换，避免一次性重写
- 多产品共用外壳：统一导航、登录与权限，业务页面各自维护
- 异构技术栈共存：不同团队使用不同框架，通过标准边界集成
- 嵌入第三方页面：以 iframe 隔离外部内容，控制其对宿主的影响
- 灰度与实验：按子应用维度放量，出问题时可单独回滚
集成方式对比
| 方式 | 特点 | 主要风险 |
|---|---|---|
| 构建时集成 | 以包依赖方式组合，类型与构建工具链统一 | 仍是整体发布，独立交付的收益有限 |
| 运行时集成 | 运行时加载远程模块，子应用可独立部署 | 公共依赖版本冲突、首屏性能与缓存策略复杂 |
| iframe | 隔离性最强，样式与脚本互不影响 | 通信、路由同步与体验一致性差 |
| Web Components | 标准封装，跨框架复用 | 样式穿透、事件规范与生态工具链尚不统一 |
子应用边界约定
子应用边界约定
# 1 路由：宿主划分子应用的路由前缀，子应用不注册全局路由
# 2 挂载：宿主提供挂载节点，子应用导出 mount/unmount 两个入口
# 3 状态：只通过宿主提供的受控接口读写登录态与权限，不直接改全局对象
# 4 依赖：公共库由宿主统一提供并固定版本，避免重复打包
# 5 埋点：统一事件字段与上报通道，保证跨子应用可联查
# 6 降级：子应用加载失败时宿主展示降级占位，不影响其他区域微前端解决的是团队交付边界问题，不是性能优化手段：为了拆而拆会让包体、依赖与联调成本同时上升。
公共依赖要定权威来源：框架版本、组件库与设计令牌由平台方维护，子应用只声明兼容范围，否则同一页面出现多个版本，样式与行为互相干扰。