微前端：大型应用拆分之道

可视化演示

巨石应用困境

一栋老牌百货大楼里，地毯柜台、家电卖场、餐饮区全挤在同一层。家电部想调整一次价签，物业必须全楼停电；餐饮部想换一根排风管道，整栋楼要停业三天。每个部门都觉得自己被拖累，又谁也离不开谁。这就是技术世界中“巨石应用”的日常：所有功能共用一个代码仓库、一个构建产物、一次部署，几十个团队在同一棵树上改枝叶。

在真实的前端项目里，巨石应用的典型特征是散落在 main 分支上的海量 merge：团队 A 改了订单列表的一个组件，团队 B 正在同一个组件上重构，合并时冲突铺满屏幕。更痛苦的是，每次发版都要所有团队对表，任何一个人没准备好，整条流水线就卡住。技术栈也被锁死在当年做技术选型时的版本里——想升级 React、想引入新的构建工具，第一步就要保证全楼不塌。

这三个代价可以浓缩成一个关系式：模块越多，交付成本越高。

百货大楼的老板看着每天停业整顿的公告唉声叹气。他心里清楚：楼不是不够大，而是“一栋楼装下所有人”的协作模式到了天花板。于是，他找来物业规划师，准备把大楼拆成一条步行街。

拆分核心思想

步行街的规划其实不复杂：物业把地块划分成若干铺位，品牌方各自装修、各自收银、各自打烊，而物业只负责公共走廊、门牌号和街区秩序。重要的是，每家店都有独立的门，顾客想进哪家就进哪家，但整条街看起来仍然是一个整体商圈。

微前端正是这样的规划思路：按业务域把前端应用拆成多个子应用，每个子应用由独立团队负责，拥有自己的代码仓库、构建流水线和部署管道。主应用承担“物业”角色，提供外壳框架——包括导航、布局、登录态——并按路由把不同页面区域交给对口的子应用渲染。子应用之间技术栈互不限制：A 团队可以用 Vue，B 团队用 React，主应用不干涉。

把所有部分拼回去，我们得到一个整体画面：

步行街的铺位各干各的，但街区空间仍是一个整体。顾客不会觉得自己进了好几家公司，只觉得“这个商场真大、真方便”——这正是微前端最迷人的地方。

沙箱隔离机制

步行街的物业非常谨慎：他们给每家店铺装了独立电闸和一键复位的保险丝盒。任何一家店短路跳闸，只会影响自己，隔壁店铺的灯光纹丝不动。在微前端世界里，这套“电闸系统”就是 JavaScript 沙箱。

子应用运行时总爱往全局 window 对象上挂东西：全局配置、实例对象、插件状态。两个子应用都声明了一个叫 window.store 的变量，后加载的会悄无声息地覆盖先加载的——就像隔壁店的电线接到你家电表上。qiankun 作为主流的微前端框架，用沙箱解决了这个冲突：激活子应用时记录它对 window 的改动，卸载时把 window 还原成激活前的样子。它提供三种沙箱实现，推荐使用的是基于 ES6 Proxy 的 ProxySandbox，性能最好，隔离最彻底。

配合沙箱的还有路由劫持。主应用监听浏览器的 hashchange 和 popstate 事件，一旦 URL 匹配到某个子应用的 activeRule 前缀，就触达该子应用的加载与挂载回调。沙箱记录下来的全局变量差异，可以表示为这样一个集合：

拉闸、合闸、再拉闸。只要保险丝盒里的记录足够准确，隔壁店铺的灯光就永远不受影响。子应用之间的“电流”从此各走各的管道，步行街恢复了井然有序的供电。

样式隔离方案

步行街的管理公约里写着一条：每家店铺可以按自己风格装修，但油漆不能刷到别人家的门脸上。这条公约映射到前端，就是“样式隔离”——因为 CSS 天生是全局的，一个子应用写的 .card { color: red }，可能覆盖另一个子应用同名类名的样式。

样式冲突的根源在于所有 CSS 最终都注入同一个页面的 style 标签里。为此，工程上发展出几套隔离手段：最朴素的是 CSS 命名空间约定——每个子应用用自己的业务前缀，比如 mall-card、order-card；进阶一点，用构建工具在编译时自动给所有选择器加上前缀；CSS Modules 则直接把类名哈希化，从源头杜绝撞名；还有动态样式表方案——子应用挂载时注入自己的样式，卸载时顺手把 style 标签摘掉。Shadow DOM 是最彻底的方式，样式被锁在组件边界内，但弹层、抽屉等挂到 body 下的组件会突破边界，需要额外处理。

样式冲突的裁决，本质是看选择器优先级，也就是特异度：

比较时从左到右逐位比大小，数值大的一方胜出。微前端要做的事情，就是让每个子应用的“油漆”只在自己的优先级角落里生效。各家涂好各家的墙，公共外立面永远由物业统一维护，步行街五彩斑斓却不混乱。

模块联邦共享

步行街运营一段时间后，物业发现一个浪费现象：三家餐饮店各自买了一台和面机、一台烤箱，每天却只用两小时。于是物业建了一个中央厨房，把烘焙设备共享出来，谁家需要谁预约。在微前端里，这个中央厨房叫 Module Federation（模块联邦）。

场景是这样的：用户、订单、营销三个子应用都依赖 React 和一套 UI 组件库。如果各自打包一份，用户访问每个子应用都要重新下载一遍重复的框架代码，首屏性能大打折扣。Webpack 5 的 Module Federation 允许应用在构建时声明“我暴露哪些模块”（exposes）和“我要引用谁的模块”（remotes），真正加载发生在浏览器运行时。更聪明的是 shared 配置：子应用们可以声明共同依赖的库，构建时只要版本兼容，就只保留一份实例，所有应用共用。

如果两个子应用对同一个库要求不同版本怎么办？这正是中央厨房会遇到的档位冲突：

中央厨房共享了设备，也带来了“档位协商”的新问题。但无论如何，比起每家店都买齐整套烤箱，资源已经节省太多。步行街的热气腾腾里，飘着的是同一间厨房的香味。

子应用通信

步行街的店铺各自独立，但有些事必须串通：用户在一家店登录了会员，另一家店也要显示同样的头像；购物车加了商品，满减活动店铺要同步更新优惠信息。物业于是定下规矩：店铺之间不直接拉网线，所有消息都通过物业的公共信箱和公告栏传递。

微前端的跨子应用通信，同样依赖一个“中间人”。常用方式有四种：URL 参数适合传递刷新后仍要保留的信息，比如从列表页跳到详情页的 id；自定义事件适合广播即时通知，任何应用都可以监听；主应用下发 props 是 qiankun 推荐的方式，父组件把回调函数传给子应用；更进一步，可以做集中式状态管理——主应用持有全局状态仓库，子应用读写通过统一接口。qiankun 的 setGlobalState 和 onGlobalStateChange 就是这套机制的官方实现。

如果把全局状态看成一个不断演进的公告板，每次更新可以写成：

任一家店铺改了菜单，物业就在公告栏贴一张通知，需要同步的铺位立刻换价签。没有人直接闯进隔壁改别人的收银系统，整条街的信息却永远保持同步。

落地实践挑战

步行街开张那天锣鼓喧天，但三个月后物业开始头疼：客流高峰时公共通道堵得水泄不通，中央厨房的设备排期越来越紧张，各家店铺的营业时间也不统一。技术图纸再漂亮，运营起来才是真正的考验。微前端落地，同样难在工程治理。

第一个挑战是首屏性能。主应用要把多个子应用的加载策略安排好：按需加载、预加载、缓存，稍有疏忽用户就要盯着白屏等三秒。第二个挑战是公共依赖管理。shared 配置需要精心设计，否则要么重复打包，要么版本冲突把页面搅得天翻地覆。第三个挑战是发布流程——子应用虽然独立部署，但灰度发布和回滚还是要跟主应用协同，先让一部分用户试用新铺子，确认没问题再全量开张。最后是团队规范：路由前缀怎么规划、生命周期命名怎么统一、跨应用的集成测试由谁负责，都需要白纸黑字写进公约。

拆分的成本曲线，可以写成一个简单的式子：

步行街要真正成功，不能只靠铺位多，更要靠一套能长期运转的物业制度。微前端不是银弹，而是一次精细的组织与技术协同手术——拆得聪明，才能走得更远。

AI 应用场景

Python 演示

# 用 Python 模拟微前端的路由分发与沙箱切换import re  class SubApp:    """子应用: 模拟一个可独立部署的前端模块"""     def __init__(self, name, prefix, mount, unmount):        self.name = name        self.prefix = prefix        self.mount = mount        self.unmount = unmount     def match(self, path):        return re.match(self.prefix, path) is not None  class MicroFrontendFramework:    """主应用框架: 负责路由匹配与生命周期调度"""     def __init__(self):        self.apps_registry = []        self.active_app_name = None     def register_app(self, app):        self.apps_registry.append(app)     def stop_current(self, name):        for app in self.apps_registry:            if app.name == name:                app.unmount()                break     def navigate(self, path):        for app in self.apps_registry:            if app.match(path):                if self.active_app_name and self.active_app_name != app.name:                    self.stop_current(self.active_app_name)                if self.active_app_name != app.name:                    app.mount()                    self.active_app_name = app.name                return app        return None  def sandbox_mount(name):    print(f"[沙箱] 开启 {name} 的隔离电闸")    print(f"[沙箱] 记录全局变量 diff: __app__ = {name}")  def sandbox_unmount(name):    print(f"[沙箱] 关闭 {name} 的隔离电闸, 还原全局变量")  def mount_mall_app():    sandbox_mount("商城应用")    print("[挂载] 商城应用: 渲染商品列表页面")  def mount_order_app():    sandbox_mount("订单应用")    print("[挂载] 订单应用: 渲染订单列表页面")  def main():    framework = MicroFrontendFramework()    framework.register_app(SubApp("商城应用", "^/mall", mount_mall_app, sandbox_unmount))    framework.register_app(SubApp("订单应用", "^/order", mount_order_app, sandbox_unmount))     for path in ["/mall/home", "/order/list", "/mall/cart"]:        print(f"\n用户访问: {path}")        framework.navigate(path)  if __name__ == "__main__":    main()

1. def match(self, path):每个子应用定义自己管理的 URL 前缀，相当于步行街上的门牌号识别规则。
2. self.apps_registry = []主框架的“铺位清单”，所有注册过的子应用都存在这张表里。
3. for app in self.apps_registry:每次路由变化，主框架逐个询问哪家铺子负责当前页面。
4. self.stop_current(self.active_app_name)切换前让旧铺子先打烊，执行卸载逻辑，还原全局变量。
5. app.mount()新铺子开业，挂载页面并开启沙箱，记录自己的全局变量改动。
6. if __name__ == "__main__":程序入口，模拟用户连续访问三个路由，观察子应用的激活与销毁顺序。

常见误区

面试题