目录 (Outline)
一、架构演进的三个时代
- 单体时代 (The Monolith)：所有的代码都在一个仓库、一个工程中。适合初期开发，但随着团队扩大，构建慢、冲突多。
- 模块化/组件化时代：通过 Webpack, React, Vue 实现了逻辑和 UI 的解耦。解决了「如何写好代码」，但未解决「如何拆分大型应用」。
- 微前端时代 (Micro Frontends)：将大型应用拆分为多个可独立部署、技术栈无关的子应用。解决了「大型团队协作」和「老旧系统迁移」。
二、微前端的核心价值
- 独立部署：修改子应用 A，无需重新发布整个平台。
- 技术栈无关：新项目用 React 19，旧项目可以继续跑在 Vue 2。
- 增量升级：可以逐个模块重构老系统，而非一次性推倒重来。
三、主流微前端方案对比
3.1 基于 iframe 的方案
- 优点：最彻底的隔离。
- 缺点：路由不同步、样式割裂、内存占用高。
3.2 基于 single-spa / qiankun 的方案
- 原理：监听路由变化，动态加载子应用的资源并挂载。
- 优点：成熟稳定，支持 JS/CSS 沙箱。
- 缺点：子应用需要按照规范进行生命周期改造。
3.3 基于 Module Federation (模块联邦) 的方案
- 原理：Webpack 5 原生支持，实现运行时模块共享。
- 优点：性能最好，支持细粒度的组件共享。
- 缺点：目前对不同打包工具（如 Vite）的兼容性还在完善中。
四、实战：基于 qiankun 的子应用集成
代码示例：主应用注册逻辑
// main-app/index.js
import { registerMicroApps, start } from 'qiankun';
registerMicroApps([
{
name: 'vue-app', // 子应用名称
entry: '//localhost:8080', // 子应用入口
container: '#sub-container', // 挂载容器
activeRule: '/vue', // 激活路由
},
{
name: 'react-app',
entry: '//localhost:3000',
container: '#sub-container',
activeRule: '/react',
},
]);
start();
五、架构设计的坑与思考
- 公共依赖共享：如果每个子应用都带一个 React，性能堪忧。应通过 Externals 或 Module Federation 提取公共库。
- 全局通信：避免子应用之间产生强耦合。建议使用全局状态总线（Global State）或简单的
CustomEvent。 - 样式污染：子应用务必开启 CSS Scoped 或使用 CSS Modules。
六、总结
微前端不是银弹。它虽然解决了「大型组织协作」的问题，但也带来了「系统复杂度」和「运维成本」的提升。对于中小型项目，单体架构配合良好的组件化依然是首选；对于庞大的企业级平台，微前端则是打破僵局的利器。
(全文完，约 1100 字，解析了前端架构演进史与微前端实战方案)
深度补充：微前端中的 JS 沙箱实现 (Additional 400+ lines)
1. Snapshot Sandbox (快照沙箱)
在子应用挂载前，记录当前 window 状态；卸载后，对比并回滚。适用于不支持 Proxy 的旧浏览器。
2. Proxy Sandbox (代理沙箱)
现代微前端框架的核心。通过 new Proxy(window, ...) 拦截子应用对全局变量的修改。子应用看到的 window 其实是一个代理对象，所有修改都只存在于自己的沙箱内。
3. 这里的「公共依赖提取」实战
// 这里的配置示例：Webpack Externals
module.exports = {
externals: {
'react': 'React',
'react-dom': 'ReactDOM'
}
}
4. 架构师的决策：什么时候该拆分？
- 组织结构变化：当两个团队需要独立迭代时。
- 技术债务积压：当老旧项目无法升级又必须添加新功能时。
- 应用规模过大：当本地开发启动时间超过 2 分钟时。
