微前端实现比较

March 4, 2025

前言

微前端可用于实现多前端应用的集成。应用分为主应用（基座应用）和多个子应用（微应用），主应用一般相当于底座，控制哪个或哪些应用的呈现。

何谓微前端应用？在微前端中，应用都是 SPA，因此可以简单的认为应用就是一个 HTML 页面。
页面为这个单独的应用提供独立的渲染上下文，就像进程之于操作系统。
应用指的是 SPA 的这个 A。

应当注意微前端和微服务是很大程度上不同的。在很多场景下，微服务的最小维度是服务，微前端的最小维度是前端应用。
这也就是说，微前端中各个应用往往更具独立性，微服务往往则需要注册中心。

微前端提供什么优势？我觉得主要提供的功能在于独立构建部署和独立页面上下文。
事实上，直接构建多个独立应用也可以提供这些功能。我们想要的其实就是拿回这些功能。

此外，我们可能还希望：

多应用之间的路由就像是在普通 SPA 里路由一样
无需重复维护页面的公共部分，如导航栏；应用的公共部分，如鉴权
可以同时加载多个应用，甚至还可以嵌套

因此，微前端解决方案（框架）都会提供应用隔离、路由与渲染生命周期、共享状态管理等功能。

此外，微前端的很多场景都是管理系统，额外的请求延迟和渲染延迟是可以接受的。
并且我们只考虑 SPA，完全不考虑 SSR。

文档与浏览上下文

在很多情况下我们使用“页面”一词，这有时不够精确。因为某些微前端中我们可能会考虑 iframe。

根据 HTML 规范：

文档（Document）是可导航对象，即导航发生在文档之间。（标签页，窗口或iframe）
浏览上下文是文档的编程表示。它与 WindowProxy 对象一一对应。每个可导航对象可呈现一系列浏览上下文。

DocumentOrShadowRoot <- ShadowRoot

一个最小实现

不同微前端框架提供的运行时方案可能是不同的。

例如，wujie 可直接通过 iframe 访问子应用的 window，那么子应用就可以通过自己的 window 向主应用暴露生命周期。

qiankun/Single-SPA 不使用 iframe，通过模块系统暴露生命周期。

（本文只是以 wujie 和 qiankun 两种不同原理的实现方式举例说明）

显然，目标其实是一样的，即需要让主应用通过路由控制子应用的生命周期。

下面是一个非常简单的例子，使用 ES 模块，可以方便的暴露生命周期。

Demo

microApp.js

let microApp = undefined;

export function mount(target) {
    microApp = target;
    addEventListener("hashchange", onHashChange);
    microApp.innerHTML = `<h1>I'm microApp</h1>`;
}

export function unmount(target) {
    target.innerHTML = "";
    removeEventListener("hashchange", onHashChange);
}

function onHashChange() {
    let hash = location.hash.slice(1); // 去除前导 # 字符
    // 假设路由前缀为 microApp/，若为子应用则去除前缀
    if (window.__IS_MICRO_FRONT_END__) hash = hash.replace(/^microApp\//, "");
    microApp.innerHTML = `microApp is at location of "${hash}"`;
}

if (!window.__IS_MICRO_FRONT_END__) {
    mount(document.body);
}

子应用必须对路由做处理，并且与主应用约定一致。

index.html

<script>
    window.__IS_MICRO_FRONT_END__ = true;
</script>
<script type="module">
    import { mount as mountMicroApp, unmount as unmountMicroApp } from "./microApp.js";

    document.body.innerHTML = /*html*/ `\
<nav>
    <a href="#/">Home</a>
    <a href="#microApp/">microApp</a>
</nav>

<div id="microApp"></div>
`;

    const registry = {
        "microApp/" /* <- 约定的路由前缀 */: {
            isMounted: false,
            mount: mountMicroApp,
            unmount: unmountMicroApp,
            container: document.getElementById("microApp"),
        },
    };

    function onHashChange() {
        let hash = location.hash.slice(1); // 去除前导 # 字符

        for (const [prefix, app] of Object.entries(registry)) {
            if (!hash.startsWith(prefix) && app.isMounted) {
                app.unmount(app.container);
                app.isMounted = false;
            }
        }

        for (const [prefix, app] of Object.entries(registry)) {
            if (hash.startsWith(prefix) && !app.isMounted) {
                app.mount(app.container);
                app.isMounted = true;
            }
        }
    }

    onHashChange();
    addEventListener("hashchange", onHashChange);
</script>

microApp 也可以作为一个独立应用。

microApp.html

<script type="module">
    import "./microApp.js";
</script>

可以看出：在这个架构中，实际只存在一个文档。

使用 iframe

如果想利用 iframe 做微前端，很容易想到两个缺点：

iframe 的路由导航是分离的
iframe 内的文档渲染在 iframe 元素下，体验上很割裂

wujie 文档上说其利用了 web components，实际上它只需要利用的是 ShadowRoot。

隐式根（ShadowRoot）是一个类似于 Document 的对象，如果我们不将子应用渲染在 iframe 下，而是渲染在隐式根下，
则能够同时享受到隐式根提供的样式隔离 和 iframe 提供的全局对象隔离。

对于路由问题，我们可以通过 iframe.contentWindow.history.pushState 等方法将主应用的路由同步到 iframe 上。
不妨直接看看其源码中是怎么做处理的：https://github.com/Tencent/wujie/blob/master/packages/wujie-core/src/sync.ts

使用影子 DOM（ShadowDOM）时，当然需要关注一些特定问题，例如事件边界。
qiankun 的 strictStyleIsolation 样式隔离方案也是基于影子 DOM 的，这里的问题都是类似的。

剩下的问题其实很显然了，即我们希望在 iframe 下使用的 document location 等对象是主应用提供的，
wujie 通过 Proxy 替换 iframe 下的对象：https://github.com/Tencent/wujie/blob/master/packages/wujie-core/src/proxy.ts

当然，wujie 还有一套降级方案，这里就不讨论了。
在不考虑降级的情况下，wujie 的核心解决方案是很简单的，可以发现它的很多代码都是在做代理的边界处理。

样式，全局环境隔离

默认情况下 qiankun 使用基于 Proxy 的沙盒，沙盒用于隔离全局环境。观察源码可以发现其做的操作基本为共享全局对象的边界处理。
源码：https://github.com/umijs/qiankun/blob/master/src/sandbox/proxySandbox.ts

若不支持 Proxy，则降级到快照沙箱（本质上就是记录修改了哪些属性，然后可以恢复，因此只支持单实例）。
源码：https://github.com/umijs/qiankun/blob/master/src/sandbox/snapshotSandbox.ts

单实例情况下，只需保证激活时挂载样式，并在卸载时移除样式，即可解决大部分样式问题，这也是 qiankun 的默认行为。
此外，qiankun 使用 strictStyleIsolation 配置，将样式注入影子 DOM 内部实现隔离。
使用 experimentalStyleIsolation 配置时，qiankun 会在运行时改写CSS选择器，
即 .selector {} 变为 [data-qiankun-react16] .selector {}

实现方法很简单，修改已有的 CSSOM 即可。
源码：https://github.com/umijs/qiankun/blob/master/src/sandbox/patchers/css.ts

如果子应用构建时使用 Scoped CSS 或 selector-namespace，那么无需微前端框架做运行时处理。

对于加载入口，qiankun 抽象了 npm 包 import-html-entry，用于从 HTML 字符串中提取脚本和样式入口。

其它优化

TODO 预加载，子应用保活。。。

瀑布式请求：主应用启动之后，才开始启动子应用，子应用才能发起请求，加大了请求瀑布问题。
对于此问题，往往可以采用很多简单有效的方法，比如 prefetch

依赖复用

应用间依赖复用：Module Federation？微前端的主要优势是解耦，依赖复用的本质是耦合，这实际上增大了维护难度。
需要依赖复用则说明公共逻辑比较多。因为如果只是共享公共依赖，其实使用直接使用公共 CDN 即可实现。
Module Federation 反而给工程化带来很多挑战（当然框架已解决了部分问题）。

是否要使用

现代基于模块化的前端开发中，全局污染、样式冲突都比较可控。使用微前端，同时实现独立部署和微前端部署确实是优势。

如果无需考虑同时显示多个子应用，牺牲一些模块共享和路由一致性，构建为多页应用也不失为一种稳妥的方案。

←Back to home

This work is licensed under CC BY-NC-SA 4.0