微前端解决的是“组织问题”：多团队并行开发、独立部署、技术栈异构。如果团队只有一个、部署也不冲突，引入微前端只会增加复杂度。
确定需要后，再谈方案：主应用 + 子应用的加载、路由、通信与隔离，每一项都有成熟的工程范式。
决策原则：团队规模与协作复杂度没有痛点时，不要为了“架构先进”而上微前端。
落地微前端要处理的关键点。
子应用动态加载与注册。
主应用与子应用路由协同。
全局状态与事件总线。
避免样式互相污染。
JS 运行环境隔离。
子应用独立构建上线。
从评估到上线的完整路径。
确认团队、部署、技术栈的真实痛点，不为了先进而先进。
对比 qiankun、模块联邦、自研方案，按团队能力决定。
搭建主应用基座，实现子应用注册、加载、路由与通信。
先迁移边界清晰的应用，验证稳定后再扩大范围，保留回退机制。
三种主流实现方式。
| 方案 | 特点 | 学习成本 | 适用场景 |
|---|---|---|---|
| qiankun | 成熟、沙箱完善 | 中 | 多数团队首选 |
| 模块联邦 | Webpack 原生、共享依赖 | 中高 | 依赖共享场景 |
| 自研 | 按需定制 | 高 | 有特殊约束时 |
会有额外加载开销，但配合预加载、缓存与合理拆分，感知不明显。要避免过度拆分子应用。
常用方案：CSS Modules、样式前缀、动态样式标签隔离。qiankun 提供沙箱兜底。
通过主应用的全局状态、事件总线或自定义事件。尽量少而明确，避免隐式耦合。
当团队合并、协作痛点消失，或微前端带来的维护成本超过收益时，就该考虑收敛回单体。
