前言：两年前的文章《乾坤微前端》中曾探讨过乾坤（qiankun）微前端实现方案。然而，在两年后再次进行微前端方案调研时，技术现状已发生明显变化。
乾坤（qiankun）的 npm 包最新版本号仍停留在 3.0.0-rc.19，近两年未有更新。其官方文档截至 2025 年 9 月也长期未维护，且提供的示例仅支持 Vue 2，缺乏持续更新支持。因此，该方案在当前微前端架构选型中已不再推荐。
基于这一背景，重新梳理了近期活跃且具备发展潜力的微前端方案。
PS: KPI项目,几年不动
腾讯无界(wujie)
技术方案
应用加载机制和 js 沙箱机制
将子应用的js注入主应用同域的iframe中运行，iframe是一个原生的window沙箱，内部有完整的history和location接口，子应用实例instance运行在iframe中，路由也彻底和主应用解耦，可以直接在业务组件里面启动应用。
路由同步机制
在iframe内部进行history.pushState，浏览器会自动的在joint session history中添加iframe的session-history，浏览器的前进、后退在不做任何处理的情况就可以直接作用于子应用
iframe 连接机制和 css 沙箱机制
采用webcomponent来实现页面的样式隔离，无界会创建一个wujie自定义元素，然后将子应用的完整结构渲染在内部
子应用的实例instance在iframe内运行，dom在主应用容器下的webcomponent内，通过代理 iframe的document到webcomponent，可以实现两者的互联。
通信机制
承载子应用的iframe和主应用是同域的，所以主、子应用天然就可以很好的进行通信，在无界我们提供三种通信方式
官网样例
single-spa
single-spa是一个目前主流的微前端技术方案，其主要实现思路：
预先注册子应用(激活路由、子应用资源、生命周期函数)
监听路由的变化，匹配到了激活的路由则加载子应用资源，顺序调用生命周期函数并最终渲染到容器
路由机制
中心化路由注册。主应用是一个“应用程序加载器”，它维护一个“应用注册表”，其中定义了每个子应用的激活条件（通常是 URL 前缀，如 activeWhen: '/react'）。当 URL 变化时，single-spa 会检查哪个应用应该被挂载或卸载，并调度其生命周期函数。
它只负责路由的“匹配”和“调度”，不负责具体的“跳转”和“显示”。子应用需要导出特定的生命周期函数（bootstrap, mount, unmount）。主应用和子应用的路由是强关联的。
数据同步机制
不提供任何内置数据通信方式。这是一个“你必须自己管理状态”的框架。
通常需要自行采用：
自定义事件 (Custom Events)：window.dispatchEvent 和 window.addEventListener。
状态管理库：在主应用初始化一个 Redux 或 Pinia store，并通过 props 传递给子应用，或者让所有应用共享一个全局状态。
Observable 模式：实现一个简单的发布订阅库。
最灵活，但也最繁琐，需要自己考虑数据隔离和冲突问题。
ps: 需要非常好的项目管理约定和管理
Garfishjs
路由机制
一体化路由系统。提供了非常完善的路由解决方案，支持“驱动式”和“托管式”两种模式。
驱动式：主应用控制路由，子应用由 Garfish 根据配置的路由激活条件进行挂载。
托管式：子应用自带路由（如 React Router、Vue Router），Garfish 会劫持路由变化，让子应用的路由系统在主应用的路由上下文中无缝运行，实现了主子和子应用的路由解耦。
路由能力是它的核心优势之一，对复杂路由场景（如子应用内部跳转、主应用跳转子应用特定路由）支持得很好。
数据同步机制
内置通信桥接器 (@garfish/bridge)
Bridge 提供了一套规范，让子应用可以安全地与主应用通信。它抹平了不同框架（React, Vue等）之间的差异，提供类似 props 传递和回调函数的方式。
主应用通过 props 向子应用传递数据。
子应用通过 garfish.globalThis 上提供的方法（如 emit）触发事件，主应用监听。
官方提供的标准化方案，安全性和可维护性比自行实现的自定义事件更高。
评论