wujie微前端框架实战踩坑与性能优化经验分享

为什么我最近总在微前端里折腾 wujie？

去年我们项目开始搞微前端，主应用是 Vue3，子应用混着 React、Vue2、甚至老 Angular。一开始试了 qiankun，确实成熟，但每次子应用加载慢得像卡碟，尤其移动端用户抱怨多。后来听说 wujie（无界）性能好，就上手试了——结果一用就回不去了。不过别急，不是所有场景都适合它，今天我就拿自己踩过的坑，说说 wujie 和其他方案到底怎么选。

谁更灵活？谁更省事？

先说结论：如果你要极致的性能和并行加载，我毫不犹豫选 wujie。但如果你团队小、子应用少、又不想折腾兼容性，qiankun 依然香。

我对比过三个主流方案：qiankun、micro-app、wujie。micro-app 虽然轻量，但社区弱，文档也糙，我试了一次就放弃了。剩下两个才是真对手。

qiankun 的优势是“稳”，阿里背书，插件生态全，生命周期钩子也全。但它的沙箱是基于 JS Proxy + iframe 隔离的，子应用必须等主应用加载完才能启动，首屏时间压不住。而 wujie 用的是 iframe + Web Worker 的组合，子应用可以和主应用并行加载，实测首屏快 30% 以上——这点在我们线上数据里特别明显。

但 wujie 也有坑：iframe 天然隔离 DOM，父子通信得靠 postMessage，写起来比 qiankun 的 props 传值麻烦。而且有些老项目用了 document.write 或 top.window，直接崩。我第一次上线就栽在这，折腾了半天才发现子应用里有个埋点脚本偷偷写了 top.location。

核心代码就这几行，但细节决定成败

来看看最简用法。wujie 的主应用集成其实很干净：

import { setupApp, bus } from 'wujie';

// 注册子应用
setupApp({
  name: 'react-app',
  url: 'https://jztheme.com/react-sub',
  exec: true,
  // 自定义 props
  props: {
    token: localStorage.getItem('token'),
    onGlobalEvent: (data) => {
      console.log('子应用发来的消息', data);
    }
  }
});

// 手动挂载
bus.$wujie?.react-app?.mount('#container');

子应用那边几乎不用改，只要确保不操作 top/window 就行。但注意：exec: true 是关键，它决定是否立即执行子应用 JS。如果设成 false，你得手动调 bus.$wujie?.xxx?.exec()，适合懒加载场景。

对比 qiankun 的写法：

import { registerMicroApps, start } from 'qiankun';

registerMicroApps([
  {
    name: 'react-app',
    entry: '//jztheme.com/react-sub',
    container: '#container',
    activeRule: '/react',
    props: { token: localStorage.getItem('token') }
  }
]);
start();

看起来 qiankun 更简洁？但背后它做了大量 JS 沙箱和样式隔离，这些在低端机上就是性能杀手。而 wujie 把隔离交给 iframe，天然安全，JS 执行也更快——只要你能接受 iframe 的限制。

踩坑提醒：这三点一定注意

第一，**子应用的 base 标签问题**。如果子应用 HTML 里有 <base href="/">，在 iframe 里会错乱。解决办法是在子应用构建时动态设置 base，或者主应用通过 props 传入正确的 publicPath。

第二，**跨域 cookie 丢失**。因为 iframe 默认不带 cookie，如果子应用依赖认证 cookie，得在主应用里提前用 fetch 预热一次接口，或者让子应用走 token 认证。我现在的做法是：登录后把 token 存 localstorage，通过 props 传给子应用，彻底绕过 cookie。

第三，**路由同步**。wujie 不自动同步主子应用路由，你得自己监听 hash 或 history 变化。比如：

// 主应用监听子应用路由变化
bus.$on('react-app-router-change', (path) => {
  window.history.pushState(null, '', /react${path});
});

虽然多写几行代码，但换来的是完全可控的路由逻辑，反而比 qiankun 的自动同步更灵活——比如我们可以做子应用内嵌 tab，而不影响主路由。

我的选型逻辑

现在我基本按这个规则来：

• 子应用超过 3 个，且对首屏性能敏感 → 选 wujie
• 子应用都是自家团队维护，技术栈统一 → 选 qiankun（开发体验更顺）
• 临时接个外部系统，生命周期短 → 直接 iframe + postMessage，别上微前端框架

上周我们新接了个第三方 BI 系统，对方只给一个 URL，还带 document.write。我试了 qiankun 直接报错，wujie 也崩，最后干脆用原生 iframe + 手动通信搞定，两天收工。有时候，简单就是最优解。

另外，wujie 最近出了 wujie-vue/wujie-react 插件，封装了 mount/unmount 逻辑，用起来更爽。比如 Vue3 里：

<template>
  <WujieVue name="react-app" :url="subAppUrl" :props="subProps" />
</template>

<script setup>
import { WujieVue } from 'wujie-vue';
const subAppUrl = 'https://jztheme.com/react-sub';
const subProps = { token: 'xxx' };
</script>

这种程度的封装，已经让我懒得回 qiankun 了。

结尾：没有银弹，只有合适

wujie 不是万能的，但它在性能和隔离性上的取舍，正好戳中了我们这类中大型项目的痛点。如果你也在被微前端的加载速度折磨，真心建议试试它——哪怕只是做个 POC，跑个 Lighthouse 对比，数据不会骗人。

以上是我踩坑后的总结，希望对你有帮助。有不同看法欢迎评论区交流，比如你们是怎么处理子应用 cookie 问题的？或者有没有更好的路由同步方案？