qiankun与Module Federation：物业式管控与仓库式共享的微前端对决

可视化演示

展示两种主流微前端方案：qiankun基于路由劫持和JS沙箱的子应用隔离、Module Federation基于Webpack5的模块共享与运行时注入、以及五维度横向对比。交互切换架构视图。

微前端概述

想象一家搬到新办公楼的科技公司。最初大家挤在同一个大平层，工位之间没有任何隔断，市场部改个海报，全楼都要一起换装修；研发部升级服务器，整层楼的 WiFi 都要断掉。公司决定按业务线重新划分空间，让每个团队拥有自己的独立办公区——这个“拆分再组合”的思路，就是微前端。

微前端不是某个框架，而是一种架构思想：把大型前端应用按业务边界拆成多个可独立开发、独立部署的子应用，再通过某种机制把它们组合成一个对用户来说完整统一的产品。它与后端微服务的理念同源，只不过切分的是浏览器里那些会互相踩脚趾的 JS 和 CSS。拆完之后，两个团队再也不用因为同一个仓库的合并冲突而互相等待。

业界落地微前端有两条主流路线。qiankun 走的是“物业式管控”：一个主应用当“壳”，负责把各个子应用装进自己的页面容器里，并提供沙箱、样式隔离等基础能力。Module Federation 走的是“仓库式共享”：它基于 Webpack5，让多个应用不仅各自独立运行，还能在运行时互相加载对方的模块，实现真正意义上的资源共享。

回到大楼的比喻：无论是请物业统一管理，还是建公共仓库共享资源，最终目的都是让这栋楼从“一锅粥”变成“井然有序的园区”。微前端要解决的就是组织协作问题，而不是单纯的技术炫技。

qiankun核心原理

访客走进一栋由物业管理的写字楼，第一步不是直接冲向楼层，而是先到前台。前台根据访客要找的人（路径），查看登记表（激活规则），然后告诉访客该去几楼几号房。qiankun 的主应用就是那个“前台”，子应用就是楼里的各个公司。

qiankun 基于 single-spa 这类微前端基座库发展而来。它通过监听浏览器地址栏的变化，在路由切换时动态决定应该由哪个子应用来接管页面的渲染。当用户访问 /order/list 时，主应用发现这个路径属于“订单应用”，于是把订单应用加载到指定的 DOM 容器中，挂载展示；当用户离开这个路径，再把它卸载清理。这一切都在运行时发生，不需要重新构建主应用。

qiankun 有两个核心设计。第一是路由劫持：它重写了 window.history 和 hashchange 事件，让路由变化时能通知所有已注册的子应用去判断自己是否该激活。第二是 HTML entry：与传统的 JS entry 不同，qiankun 允许子应用直接暴露一个 HTML 文件地址，主应用像浏览器一样去 fetch 这个 HTML，然后解析出里面的 JS 和 CSS 再执行——这意味着子应用可以用任何技术栈开发，Vue、React、Angular、甚至原生 JS 都能接入。

物业前台的比喻在这里非常贴切：qiankun 的重担就是“正确地引导访客”，而这依赖一张清晰的登记表（路由规则）。一旦登记表混乱，访客就会走错楼层——这也是微前端架构中最常见的翻车现场。

JS沙箱机制

物业为了防止租户之间互相干扰，给每个商铺装上了独立电表和门禁系统。租户在自己屋里开多少空调、装多少电器都行，但电费只走自己的表；租户退租时，物业把屋子恢复到初始状态，下一位租户进来时看到的还是那间干净的空房。qiankun 的 JS 沙箱做的就是这件事。

子应用运行时会往全局对象 window 上挂载各种变量、设置定时器、绑定事件监听器。如果不做隔离，子应用 A 卸载后，它在 window 上留下的全局变量会继续存在，可能覆盖子应用 B 的同名变量，导致数据错乱甚至白屏。qiankun 提供了快照沙箱和代理沙箱两种主流方案来解决这个问题。

快照沙箱的原理很朴素：子应用激活前，把 window 上所有属性复制一份快照；子应用运行期间随意修改；卸载时，遍历快照把所有属性恢复原状。代理沙箱则更优雅：它利用 ES6 的 Proxy 给 window 套了一层拦截器，子应用读取某个属性时先查虚拟环境，查不到再找真实 window；写属性时只写入虚拟对象，真实 window 完全不被触碰。代理沙箱性能更好，也是 qiankun 默认推荐的方式。

电表不会因为楼上租户多开了一台空调而跟着跳闸，代理沙箱也不会因为子应用 A 写了几个全局变量而影响子应用 B 的运行。沙箱是微前端信心的基石，但记住它只负责 JS 的隔离，CSS 的隔离还得靠下一节的招数。

样式隔离方案

商场物业对每间店铺的装修有一条硬性规定：店铺招牌必须带商场统一的编号前缀，比如 A-301、B-205。这样即使两家店都卖奶茶，顾客也不会走错门。CSS 样式隔离的思路也是如此——给每个子应用的样式起一个“带编号的名字”。

子应用的 CSS 默认是全局的，如果子应用 A 写了 .btn { background: red }，子应用 B 也写了 .btn { background: blue }，后加载的样式会覆盖先加载的，页面颜色就乱了。qiankun 提供了三种层次的样式隔离手段。最彻底的是 Shadow DOM 严格隔离：把子应用的 DOM 放进一个 shadowRoot 里，浏览器天然保证内外样式互不可见，但这种方案对弹窗、浮层等挂载到 body 下的元素无能为力。

第二层是实验性样式隔离：qiankun 在运行时扫描子应用加载的样式表，给每个选择器加上一个带应用名前缀的属性选择器，比如 .btn 变成 .order-app .btn，这样即使两个应用都有 .btn，作用域也不同。第三层则是团队约定：大家约好每个类名都带命名空间，比如 .order-btn、.user-avatar，用代码规范代替运行时开销。这三种方案可以组合使用，实际项目中最常见的是“实验性隔离 + 命名约定”双保险。

装修再美观，招牌编号乱了也会让人走错门。样式隔离不一定需要做到 100% 物理隔离，能让两个团队在各自的“命名空间”里安心写样式，就已经解决了 90% 的冲突问题。

模块联邦原理

如果说 qiankun 是请物业来管楼，Module Federation 就是干脆让每个团队自己建楼，然后在园区中心修一座“中央共享仓库”。市场部需要一套模板组件，不用自己造轮子，直接从仓库里拿；研发部升级了共享工具库，所有楼群第二天自动用上新版本。

Module Federation 是 Webpack5 内置的模块共享能力。它在构建阶段通过 ModuleFederationPlugin 插件声明两件小事：本应用要“暴露”哪些模块给别人（exposes），以及本应用要“借用”哪些共享依赖（shared）。构建完成后，每个应用还是一个独立的可部署产物，但产物里多了一份“远程模块的引用地图”，真正加载远端模块发生在浏览器运行时。

模块联邦解决的是“运行时依赖注入”问题：应用 A 的代码里可以 import('appB/Button')，构建时 Webpack 不打包这份代码，而是生成一个运行时加载函数；当浏览器执行到这行代码时，才去应用 B 的服务器上请求 Button 模块。同时，shared 机制还能让多个应用共享同一个 React 实例，避免重复加载导致的状态不同步。这种“用的时候才去拿”的方式，比把所有公共代码打进每个应用的包里高效得多。

中央仓库的意义在于“人人可共享、处处不重复”。但仓库也需要管理规则：谁负责维护共享包的质量？版本升级如何通知所有群租楼？这些问题在部署与版本管理部分会进一步展开。

通信机制设计

大楼里的商户之间免不了要传递消息：奶茶店要向会员中心确认顾客的积分，商场广播要通知所有店铺新的促销活动。微前端里的子应用通信，就是设计一套清晰的“传话系统”，让消息不靠吼，而是走正规渠道。

qiankun 和 Module Federation 都支持多种通信方式，团队可以根据耦合程度选择。第一种是 props 透传：主应用在挂载子应用时，把需要的数据和方法作为 props 传进去。这像物业在店铺开业时递上一本《商户手册》——一次性给到位。第二种是全局状态管理：在主应用中维护一个全局状态容器（比如 Redux 或 Zustand），子应用通过订阅状态变化来响应更新，适合跨应用共享登录态、用户信息等高频数据。第三种是自定义事件：通过浏览器的 window.dispatchEvent 和 addEventListener 实现事件广播，最适合松耦合的“通知型”通信，比如“订单已创建，请刷新列表”。

通信设计最怕的是“没有约定”。如果所有子应用都直接 import 一个全局单例对象，改动时牵一发动全身，耦合度比单体应用还高。所以微前端的最佳实践是把通信协议文档化：哪些数据用 props 注入、哪些状态进全局 store、哪些消息走事件总线，都事先约定清楚。

回到商场比喻：传话系统越规范，商户之间的协作越顺畅。无论是物业手册（props）还是商场广播（事件），关键是让每个商户知道“该听谁的广播、该按哪本手册办事”，而不是遇到问题就伸长脖子喊一嗓子。

部署差异对比

请物业管理的商场和各自建楼的产业园，在“盖房子”这件事上的流程完全不同。商场是统一规划、分店铺装修；产业园是各家独立施工、再修路连通。qiankun 和 Module Federation 的部署差异，恰好也具有这种结构性的不同。

qiankun 的部署模式是“一个壳 + 多个独立子应用”。主应用和各子应用分别构建、分别部署到不同的静态服务器或 CDN 路径上。主应用通过配置的子应用 HTML 地址去加载它们，所以子应用发版完全不需要主应用重新构建——这非常适合多团队并行发布的场景。版本管理也简单：每个子应用的 URL 就是它的版本号，切换版本只需更新主应用的注册配置。

Module Federation 的部署模式则更接近“统一构建生态”。虽然每个应用也是独立部署，但由于存在运行时互相加载的依赖关系，远端模块一旦发布新版本，所有引用它的宿主应用在下次访问时会自动拿到新代码。好处是模块复用极高效，风险是版本失控：一个远端应用发布了一个破坏性变更，可能让所有宿主应用同时报错。因此 MF 的版本管理必须更精细，常见的策略是 shared 依赖制定版本范围，并结合构建时的 requiredVersion 校验。

商场有商场的规范，产业园有产业园的自由。qiankun 的部署模式对运维友好、故障隔离直观；MF 的部署模式对共享高效、但需要更强的工程治理能力。选择哪种，取决于你们团队能不能驾驭“自由的代价”。

选型实践指南

面对物业和中央仓库两种方案，决策者不该拍脑袋，而要像技术委员会一样系统地评估三个维度：团队规模、技术栈匹配、共享需求强度。

如果团队规模大、技术栈杂、业务系统多，需要清晰的“壳 + 子应用”边界来治理，qiankun 是更稳妥的选择。它接入成本低，对已有系统的侵入性小，子应用可以用任何框架改造，甚至老旧的 jQuery 项目也能慢慢迁移进来。如果团队规模小、技术栈统一、多个应用之间有大量需要复用的业务组件和公共依赖，Module Federation 会更顺手——它把共享写进了构建工具里，不用像 qiankun 那样在运行时做层层包裹。

技术栈匹配也很关键：项目还在用 Webpack4，迁移到 MF 需要先升级 Webpack5，工作量大；而 qiankun 对构建工具没要求。反过来，如果团队本来就在 Webpack5 上，而且痛点不是“应用隔离”而是“模块复用”，那 MF 的优势就非常明显。最后是治理能力：MF 的运行时共享虽然灵活，但版本失控和循环依赖风险都需要强大的工程规范来兜底；qiankun 的沙箱和样式隔离则更像“强制纪律”，天然约束了子应用的越界行为。

选物业还是建仓库，没有标准答案，只有“最适合你们园区现状”的答案。更聪明的做法是认识到两者并不对立：qiankun 可以装入用 MF 构建的子应用，两种方案可以组合使用，让物业管隔离、仓库管共享。

AI 应用场景

Python 演示

"""模拟微前端两种方案：qiankun 的沙箱隔离与 Module Federation 的共享模块。"""  class App:    """一个微前端子应用，模拟注册时的基本信息。"""     def __init__(self, name, active_rule):        self.name = name        self.active_rule = active_rule     def match(self, path):        """判断当前路由是否命中本应用。"""        return path.startswith(self.active_rule)  class QiankunSandbox:    """模拟 qiankun 快照沙箱：激活时记录，卸载时还原。"""     def __init__(self, window_env):        self.window_env = window_env        self.snapshot = {}        self.modified_keys = set()     def grant(self):        self.snapshot = dict(self.window_env)     def set_attr(self, key, value):        self.window_env[key] = value        self.modified_keys.add(key)     def revoke(self):        for key in self.modified_keys:            if key in self.snapshot:                self.window_env[key] = self.snapshot[key]            else:                del self.window_env[key]        self.modified_keys.clear()  class ModuleFederationRegistry:    """模拟 Module Federation 的共享模块池。"""     def __init__(self):        self.module_pool = {}     def get_or_create(self, module_name, version, factory):        pool_key = (module_name, version)        if pool_key not in self.module_pool:            self.module_pool[pool_key] = factory()        return self.module_pool[pool_key]  def main():    # qiankun 场景：子应用运行期间修改全局变量，卸载后还原    window_env = {"currentTheme": "light"}    sandbox = QiankunSandbox(window_env)     sandbox.grant()    sandbox.set_attr("currentTheme", "dark")    print("子应用运行期间:", window_env)     sandbox.revoke()    print("子应用卸载后还原:", window_env)     # Module Federation 场景：多个应用共享同一个模块实例    registry = ModuleFederationRegistry()    react_a = registry.get_or_create("react", "18.2.0", lambda: {"name": "react"})    react_b = registry.get_or_create("react", "18.2.0", lambda: {"name": "duplicate"})    print("两个应用拿到同一份 React?:", react_a is react_b)  if __name__ == "__main__":    main()

1. def match(self, path):每个子应用声明自己的路由激活规则，类似物业前台查登记表决定访客去向。
2. self.snapshot = dict(self.window_env)子应用启动前给 window 拍快照，记录修改前的原始状态。
3. self.window_env[key] = value子应用运行期间可以修改全局对象，模拟真实业务的全局变量写入。
4. if key in self.snapshot: self.window_env[key] = self.snapshot[key]卸载时用快照还原，清理子应用的全局污染。
5. pool_key = (module_name, version)MF 按“名字 + 版本”作为共享模块的键，避免不同版本的模块互相覆盖。
6. if pool_key not in self.module_pool:命中共享则直接复用，不命中才执行 factory 创建新实例，这就是单例共享的原理。

常见误区

面试题