微前端狂想曲：我试图让三个不同门派的前端住进同一栋楼

微前端狂想曲我试图让三个不同门派的前端住进同一栋楼某天深夜我盯着一个巨大的 node_modules突然冒出一个疯狂的想法如果前端应用不是一整块铁板而是一堆乐高积木呢序章一个被“巨兽”压垮的夜晚那天晚上我打开了一个自己维护了三年的个人项目。它一开始很小只是一个用 Vue 写的工具页。后来我想加个博客于是塞了个 React 的编辑器进去。再后来我又想加个音乐播放器用原生 JS 写的也挂在了同一个页面上。结果这个项目变成了一个“三不像”。Vue 的组件和 React 的组件在同一棵 DOM 树里打架。样式互相污染一个 .button 改得全局崩溃。打包出来的 bundle.js 有 4MB每次改一行字都要重新构建。发布时整个应用一起上线博客改个错别字播放器也得跟着“重启”。我盯着屏幕心里冒出一个念头“我为什么要把它们塞进同一个应用里它们明明可以各自独立又能出现在同一个页面上啊。”这个念头就是微前端的起点。第一章微前端是什么——不是技术是“分而治之”的哲学很多人以为微前端是一种框架、一个库。其实不是。微前端是一种架构思想把一个大的前端应用拆成多个小的、独立的、可以单独开发、单独部署、单独运行的应用再把它们组合成一个整体。用漫画来比喻的话单体应用一栋大楼所有房间都在同一张图纸上改一个房间要动整栋楼的结构。微前端一栋“合租公寓”每个房间有自己的门锁、自己的装修风格、自己的租客但共用同一个大门、同一个走廊、同一个水电系统。租客之间互不干扰但对外看起来它们是一栋楼。这就是微前端的核心魅力独立与统一的平衡。第二章四种“合租方案”的漫画对决当我开始研究怎么实现微前端时我发现了四条路。它们就像四种不同的合租方案各有各的脾气。方案一iframe —— 最老派也最省心【分镜】一个铁皮箱子里面装着一个完整的小世界。箱子外面贴着一张纸条“别碰我我自己能活。”iframe 是最原始的微前端方案。每个子应用跑在一个独立的 iframe 里拥有自己的window、自己的document、自己的 CSS 和 JS。优点天然隔离样式不冲突JS 不污染。子应用可以用任何技术栈完全不用管主应用。缺点通信靠 postMessage像隔墙喊话。路由同步麻烦刷新页面容易丢状态。弹窗、遮罩层只能在 iframe 内部显示不能覆盖整个页面。性能开销大每个 iframe 都是一个独立的浏览器上下文。我的感想iframe 像“合租但各自带锁的房间”安全但孤独。适合集成老系统不适合追求体验的现代应用。方案二Web Components —— 原生但生态弱【分镜】一个标准化的插头不管你是哪国电器插上就能用。Web Components 是浏览器原生支持的组件化方案。你可以用my-app这样的自定义标签把子应用封装成一个组件。优点浏览器原生不依赖框架。Shadow DOM 提供天然的样式隔离。缺点生态不成熟和 Vue/React 集成需要额外适配。路由、通信、状态管理都得自己造轮子。兼容性虽然好了很多但仍有坑。我的感想Web Components 像“标准插头”理念很美但现实中的电器五花八门插头标准还没统一。方案三qiankun —— 社区里的“物业公司”【分镜】一个穿着制服的物业管家手里拿着一本《合租公约》负责协调所有租客。qiankun 是基于 single-spa 的微前端框架在国内非常流行。它帮你处理了路由劫持、JS 沙箱、样式隔离、资源加载等脏活累活。优点开箱即用接入成本低。支持 HTML Entry子应用几乎不用改代码。生态成熟文档齐全。缺点沙箱不是 100% 隔离某些全局变量仍会泄漏。对 Vite、Webpack 5 的支持需要额外配置。主应用和子应用的技术栈仍然有一定耦合。我的感想qiankun 像“物业公司”帮你搞定大部分琐事但你还是得遵守它的规则。方案四Module Federation —— 共享仓库的“模块联邦”【分镜】几个房间共用一个仓库谁需要什么直接去仓库拿不用自己造。Module Federation 是 Webpack 5 引入的特性它让不同的应用可以互相共享模块。比如主应用可以直接import子应用暴露出来的组件。优点真正的模块共享运行时动态加载。适合多个应用共享公共依赖如 React、Vue。构建时解耦运行时集成。缺点强依赖 Webpack 5对 Vite 等构建工具支持有限。版本管理复杂共享模块的版本冲突需要小心处理。学习曲线较陡。我的感想Module Federation 像“共享仓库”效率极高但前提是大家都用同一套仓储系统。第三章我的构想——一个“前端宇宙”研究完这些方案后我开始幻想一个更理想的微前端世界。我把它叫做“前端宇宙”。主应用是引力场负责提供导航、布局、用户认证、全局状态。子应用是一颗颗行星各自独立运转有自己的技术栈、自己的发布周期、自己的团队哦不自己的“居民”。通信机制是引力波主应用和子应用之间通过事件总线或共享状态传递信息。样式隔离是大气层每个星球有自己的环境不会污染别人。路由是星际航道用户可以在不同星球之间穿梭URL 同步变化。在这个宇宙里我可以用 Vue 写博客用 React 写音乐播放器用 Svelte 写待办清单。每个子应用独立开发、独立部署互不影响。主应用只负责“把它们拼在一起”不关心它们内部怎么实现。用户感觉不到切换就像在一个应用里浏览。这个构想让我兴奋了很久。但很快我冷静下来开始思考它的代价。第四章微前端的“暗面”——复杂度不会消失只会转移微前端不是银弹。它解决了一些问题但引入了新的问题。性能多个子应用意味着多次资源加载、多个运行时。首屏可能更慢。通信主应用和子应用之间如何传递数据事件总线全局状态Props每一种都有坑。样式隔离Shadow DOM 不兼容所有 UI 库CSS Modules 需要构建时支持qiankun 的沙箱也不是万能的。路由主应用和子应用的路由如何同步刷新页面时如何恢复到正确的子应用版本管理子应用依赖的公共库版本不一致怎么办调试错误堆栈跨应用定位问题更难。部署子应用独立部署但主应用需要知道它们的地址配置管理变复杂。最扎心的是如果你只有一个团队、一个技术栈、一个发布节奏微前端可能完全是过度设计。第五章我到底需不需要微前端这个问题我問了自己很多遍。如果你的项目满足以下条件微前端可能适合你多个团队独立开发发布节奏不同。技术栈不统一需要渐进式迁移。应用规模巨大单体构建和部署已经难以忍受。需要集成老系统又不想重写。但如果你的项目是一个人维护的小项目。技术栈统一发布节奏一致。规模不大构建速度还能接受。那微前端可能只会给你添乱。我的结论是微前端是一种“权衡”不是一种“进化”。它用复杂度换独立性用性能换灵活性。值不值得取决于你的场景。终章前端世界分久必合合久必分从 jQuery 到 Angular从 React 到 Vue从前端路由到微前端前端世界一直在“分”与“合”之间摇摆。微前端不是终点它只是这个时代的一种答案。它回答了一个问题当应用大到一定程度如何让它继续可维护、可扩展、可独立演进也许未来会有更好的方案。也许 Web Components 会崛起也许 Module Federation 会成为主流也许浏览器会原生支持微前端。但无论技术怎么变“分而治之”的思想不会变。而我对微前端的构想也会继续生长。P.S. 写完这篇文章后我把那个“三不像”项目拆成了三个独立应用用 qiankun 拼在一起。构建时间从 3 分钟降到了 30 秒但调试时间从 30 秒涨到了 3 分钟。P.P.S. 微前端真是一门“平衡的艺术”。