无界（微前端框架）

微前端是什么

微前端是一种多个团队通过独立发布功能的方式来共同构建现代化 web 应用的技术手段及方法策略，通俗来说就是在一个web应用里面嵌套另一个web应用

微前端有什么使用场景呢？

举例

比如制作一个企业管理平台，把已有的采购系统和财务系统统一接入这个平台；比如有一个巨大的应用，为了降低开发和维护成本，分拆成多个小应用进行开发和部署，然后用一个平台将这些小应用集成起来；又比如一个应用使用vue框架开发，其中有一个比较独立的模块，开发者想尝试使用react框架来开发，等模块单独开发部署完，再把这个模块应用接回去

我接触的项目中 H+（乾坤）F+（iframe嵌套项目）乐学（iframe嵌套一些视频和PDF）

一个完善的的微前端框架应该具备哪些能力呢？

能力

子应用的加载和卸载能力

页面需要从一个子应用切换到另一个子应用，框架必须具备加载、渲染、切换的能力

子应用独立运行的能力

子应用运行会污染全局的 window 对象，样式会污染其他应用，必须有效的隔离起来

子应用路由状态保持能力

激活子应用后，浏览器刷新、前进、后退子应用的路由都应该可以正常工作

应用间通信的能力

应用间可以方便、快捷的通信

使用微前端有什么收益呢？

收益

技术栈无关

主框架不限制接入应用的技术栈，微应用具备完全自主权

独立开发、独立部署

微应用仓库独立，前后端可独立开发，部署完成后主框架自动完成同步更新

增量升级

在面对各种复杂场景时，我们通常很难对一个已经存在的系统做全量的技术栈升级或重构，而微前端是一种非常好的实施渐进式重构的手段和策略

独立运行时

每个微应用之间状态隔离，运行时状态不共享

直接使用iframe不就可以做到吗？

iframe 方案

采用iframe的方案确实可以做到，而且优点非常明显

优点

非常简单，使用没有任何心智负担web应用隔离的非常完美，无论是js、css、dom都完全隔离开来

由于其隔离的太完美导致缺点也非常明显

缺点

路由状态丢失，刷新一下，iframe的url状态就丢失了dom割裂严重，弹窗只能在iframe内部展示，无法覆盖全局web应用之间通信非常困难每次打开白屏时间太长，对于**SPA 应用**来说无法接受

single-spa 方案​

**single-spa**在2025年仍是主流的微前端技术方案之一，但已不再是唯一主流。其核心优势在于技术栈无关性，支持React、Vue、Angular等不同框架的模块共存，且生命周期管理机制成熟。其主要实现思路：

预先注册子应用(激活路由、子应用资源、生命周期函数)监听路由的变化，匹配到了激活的路由则加载子应用资源，顺序调用生命周期函数并最终渲染到容器

**乾坤**微前端架构则进一步对single-spa方案进行完善，主要的完善点：

子应用资源由 js 列表修改进为一个url，大大减轻注册子应用的复杂度实现应用隔离，完成js隔离方案 （ window工厂）和css隔离方案 （类vue的scoped的）增加资源预加载能力，预先子应用html、js、css资源缓存下来，加快子应用的打开速度

总结一下方案的优缺点：

优点

监听路由自动的加载、卸载当前路由对应的子应用完备的沙箱方案，js沙箱做了SnapshotSandbox、LegacySandbox、ProxySandbox三套渐进增强方案，css沙箱做了两套strictStyleIsolation、experimentalStyleIsolation两套适用不同场景的方案路由保持，浏览器刷新、前进、后退，都可以作用到子应用应用间通信简单，全局注入

缺点

基于路由匹配，无法同时激活多个子应用，也不支持子应用保活改造成本较大，从 webpack、代码、路由等等都要做一系列的适配css 沙箱无法绝对的隔离，js沙箱在某些场景下执行性能下降严重无法支持 vite 等 ESM脚本运行

无界方案​

在乾坤中有一个**议题**，有开发者提出能否利用iframe来实现js沙箱能力，这个想法启发了无界方案，下面详细介绍

应用加载机制和 js 沙箱机制​

将子应用的js注入主应用同域的iframe中运行，iframe是一个原生的window沙箱，内部有完整的history和location接口，子应用实例instance运行在iframe中，路由也彻底和主应用解耦，可以直接在业务组件里面启动应用。

采用这种方式我们可以获得

收益

组件方式来使用微前端

不用注册，不用改造路由，直接使用无界组件，化繁为简

一个页面可以同时激活多个子应用

子应用采用 iframe 的路由，不用关心路由占用的问题

天然 js 沙箱，不会污染主应用环境

不用修改主应用window任何属性，只在iframe内部进行修改

应用切换没有清理成本

由于不污染主应用，子应用销毁也无需做任何清理工作

运行模式

路由同步机制​

收益

浏览器刷新、前进、后退都可以作用到子应用 实现成本低，无需复杂的监听来处理同步问题 多应用同时激活时也能保持路由同步

iframe 连接机制和 css 沙箱机制​

无界采用**webcomponent**来实现页面的样式隔离，无界会创建一个wujie自定义元素，然后将子应用的完整结构渲染在内部

子应用的实例instance在iframe内运行，dom在主应用容器下的webcomponent内，通过代理 iframe的document到webcomponent，可以实现两者的互联。

将document的查询类接口：getElementsByTagName、getElementsByClassName、getElementsByName、getElementById、querySelector、querySelectorAll、head、body全部代理到webcomponent，这样instance和webcomponent就精准的链接起来。

当子应用发生切换，iframe保留下来，子应用的容器可能销毁，但webcomponent依然可以选择保留，这样等应用切换回来将webcomponent再挂载回容器上，子应用可以获得类似vue的keep-alive的能力.

采用这种方式我们可以获得

收益

天然 css 沙箱

直接物理隔离，样式隔离子应用不用做任何修改

天然适配弹窗问题document.body

的appendChild或者insertBefore会代理直接插入到webcomponent，子应用不用做任何改造

子应用保活

子应用保留iframe和webcomponent，应用内部的state不会丢失

完整的 DOM 结构

webcomponent保留了子应用完整的html结构，样式和结构完全对应，子应用不用做任何修改

通信机制​

承载子应用的iframe和主应用是同域的，所以主、子应用天然就可以很好的进行通信，在无界我们提供三种通信方式

props 注入机制

子应用通过$wujie.props可以轻松拿到主应用注入的数据 window.parent 通信机制

子应用iframe沙箱和主应用同源，子应用可以直接通过window.parent和主应用通信

去中心化的通信机制

无界提供了EventBus实例，注入到主应用和子应用，所有的应用可以去中心化的进行通信

优势​

通过上面原理的阐述，我们可以得出无界微前端框架的几点优势：

优势

多应用同时激活在线

框架具备同时激活多应用，并保持这些应用路由同步的能力

组件式的使用方式

无需注册，更无需路由适配，在组件内使用，跟随组件装载、卸载

应用级别的 keep-alive

子应用开启**保活模式后，应用发生切换时整个子应用的状态可以保存下来不丢失，结合预执行模式**可以获得类似ssr的打开体验

纯净无污染无界利用iframe和webcomponent来搭建天然的js隔离沙箱和css隔离沙箱利用iframe的history和主应用的history在同一个**top-level browsing context来搭建天然的路由同步机制副作用局限在沙箱内部，子应用切换无需任何清理工作，没有额外的切换成本性能和体积兼具子应用执行性能和原生一致，子应用实例instance运行在iframe的window上下文中，避免with(proxyWindow){code}这样指定代码执行上下文导致的性能下降，但是多了实例化iframe的一次性的开销，可以通过 preload 提前实例化体积比较轻量，借助iframe和webcomponent来实现沙箱，有效的减小了代码量开箱即用**

不管是样式的兼容、路由的处理、弹窗的处理、热更新的加载，子应用完成接入即可开箱即用无需额外处理，应用**接入成本**也极低

无界（Wujie）

核心特点：是一个跨框架的微前端解决方案，核心目标是打破不同技术框架之间的壁垒，实现微应用在不同框架下的无缝集成。它能让使用 Vue.js、React.js、Angular 等不同框架的微应用，在同一个主应用中和谐共处。‌优势**‌：极致隔离、低通信延迟，支持Vite和预加载实现原理：基于 “WebComponent + iframe” 来实现，js 通过 iframe 来隔离，css 通过 webcomponent + shadowdom 来隔离。

乾坤（Qiankun）

核心特点：由蚂蚁金服开源，具有强大的微应用管理和加载能力，能很好地支持企业级复杂应用的微前端架构改造。优势**‌：支持HTML Entry、预加载，适合大型后台系统改造实现原理：基于 “single - spa” 方案，使用 “function + proxy + with” 实现。

如果项目对兼容性要求较高，特别是需要兼容 IE11，那么乾坤可能更合适；如果项目是新技术栈，对 Vite 等支持要求高，且希望接入成本低，那么无界可能是更好的选择。当然，具体的选择还需要根据项目的实际情况，如团队技术栈、业务场景、性能要求等多方面因素来综合考虑。