什么是无界微前端？
无界微前端（Wujie） 是一个基于 iframe
强隔离特性的微前端框架。
它旨在解决构建大型复杂前端应用时遇到的团队协作、技术栈多样性、应用解耦以及集成效率等问题。
不同于一些基于 MutationObserver
或代理捕获的沙箱方案，无界利用原生 iframe 提供的天然隔离能力，为子应用提供了一个独立运行的环境，从而最大程度地避免了不同应用之间的全局变量污染、样式冲突和 DOM 结构干扰。
无界的核心思想是利用一个轻量级的 runtime，在主应用中通过创建和管理 iframe 容器来承载子应用。
它并非简单地嵌入 iframe，而是在此基础上进行了增强，解决了纯 iframe 使用时遇到的诸多痛点，例如：
- 跨应用通信
- 路由同步
- 样式隔离优化
- 脚本加载与执行控制
- 应用生命周期管理
因此，无界可以被理解为一个在 iframe 原生隔离基础上构建的、提供了完善的微前端解决方案的工具。
为什么选择无界微前端？
选择无界作为微前端解决方案，通常是看中了其在特定方面的优势，尤其是在 隔离性 和 易用性 上：
极强的隔离能力
无界利用 iframe 实现了对全局变量、事件监听、DOM 结构等的完全隔离。每个子应用都在自己的 iframe 上下文中运行，拥有独立的 window、document、history 等对象。这比基于 Proxy 或 快照 的沙箱方案更加彻底和原生，可以有效避免许多复杂的沙箱逃逸问题，尤其是在集成一些对环境有强依赖或包含复杂第三方库的子应用时，这种隔离优势尤为突出。
开箱即用的高兼容性
得益于 iframe 提供的独立运行环境，子应用无需为了集成到微前端框架而修改自身的构建配置或运行时逻辑。理论上，任何能够在独立页面中运行的前端应用（无论使用何种框架，如 React, Vue, Angular, 或者原生 JS）都可以轻松地接入无界。这种零代码侵入的特性大大降低了微前端改造的成本和风险，尤其适合对现有大型应用进行渐进式改造。
相对优秀的性能
无界在 iframe 的基础上，对加载和渲染流程进行了优化。例如，它可以支持子应用的预加载，在用户访问前就将子应用的资源加载并渲染到不可见的 iframe 中，从而实现子应用秒开的体验。此外，由于子应用运行在独立的 iframe 中，其内部的重绘和回流通常不会影响到主应用或其他子应用，这有助于保持整个应用的流畅性。
简化了样式隔离
iframe 天然提供了样式隔离能力，子应用中的 CSS 默认不会影响到主应用或其他 iframe 中的样式。无界在此基础上，还提供了更细粒度的样式控制选项，例如通过 Shadow DOM
进一步增强隔离，或者允许特定样式穿透。这极大地简化了微前端环境中棘手的样式冲突问题。
无界微前端通常在哪里使用？
无界微前端特别适合以下几种应用场景：
- 巨石应用改造（Monolith Refactoring）： 当一个大型单体应用变得难以维护、迭代效率低下时，可以考虑将其按照业务模块拆分成独立的子应用，然后使用无界作为壳应用（主应用）来集成这些子应用。这允许团队独立开发、测试和部署各自负责的模块，逐步解耦。
- 多技术栈并存： 在一个大型组织中，不同的团队可能使用了不同的前端技术栈（例如，遗留系统使用 AngularJS 或 Vue 2，新项目使用 React 或 Vue 3）。无界可以很方便地将这些使用不同框架构建的应用集成到同一个父应用中，避免强制统一技术栈，保护历史投资。
- 跨部门协作： 不同的业务部门负责开发不同的功能模块，这些模块需要在一个统一的用户界面中呈现。无界能够让各部门独立开发和部署，同时通过主应用进行集成和协调，提高并行开发效率。
- 第三方或遗留系统集成： 有时需要在现有应用中嵌入一个完全独立的第三方应用或一个难以改造的遗留系统模块。由于无界提供了强大的隔离能力和低侵入性，非常适合用来安全地嵌入这些外部或老旧的应用。
- 应用沙箱/演示环境： 构建一个可以在主应用中安全运行不受信任代码或演示不同应用版本/功能的沙箱环境。
无界微前端如何提供隔离？
无界提供隔离的核心机制是基于 iframe 的原生隔离能力，并在此基础上进行增强。
具体来说，它是这样工作的：
- 创建 iframe 容器： 当需要加载一个子应用时，无界会在主应用中动态创建一个不可见的 iframe 元素，并将其添加到 DOM 中。这个 iframe 拥有一个独立的浏览上下文。
- 劫持加载过程： 无界会劫持 iframe 的内容加载。它不会直接让 iframe 加载子应用的完整 HTML 页面，而是通过某种方式（例如，修改 document.write、利用 blob URL 或 data URL 等技术）在 iframe 的 document 内部构建子应用所需的环境。
- 注入子应用资源： 无界会将子应用的 HTML、CSS、JavaScript 等资源通过特定的方式注入到 iframe 的环境中执行。这里的关键在于资源的加载和执行是在 iframe 的上下文中进行的，而非主应用的全局上下文。
- 沙箱增强： 尽管 iframe 提供了基础隔离，但为了实现微前端所需的功能（如通信、路由同步等），无界需要在 iframe 的 window 对象上进行一些必要的代理或修改，以便主应用和子应用之间可以进行有限且安全的交互。同时，它还会处理一些 iframe 原生行为的副作用，例如滚动条、历史栈等。
- 样式隔离优化： 对于 CSS，iframe 本身就提供了很强的隔离。无界可能还会结合 Shadow DOM 等技术，或者提供 post-processing 能力，进一步确保子应用样式不会泄露或冲突。
通过上述机制，无界为每个子应用创建了一个“干净”且独立的运行空间，极大地减少了不同应用之间相互影响的可能性。这种隔离是“强”隔离，因为它依赖的是浏览器提供的原生安全边界。
主应用与子应用之间如何通信？
在无界微前端架构中，主应用和子应用之间需要进行数据交换和事件通知。无界提供了多种通信机制：
- Props 传递： 在主应用加载或挂载子应用时，可以通过配置选项将数据以 props 的形式传递给子应用。这适用于初始化时的配置信息传递。
-
Event Bus (事件总线)： 无界提供了一个内置的事件总线机制。主应用和子应用都可以访问同一个事件总线实例，通过订阅（
bus.on）和发布（bus.emit）事件来进行灵活的异步通信。这是最常用的跨应用通信方式，适用于解耦的消息通知。例如，在主应用中触发一个事件：
Wujie.bus.$emit('eventName', data);在子应用中监听该事件：
window.$wujie.bus.$on('eventName', (data) => {
console.log('Received data from host:', data);
}); - Ref 访问（有限）： 在某些情况下，主应用可能可以通过获取子应用的实例引用（如果无界提供了这样的 API）来直接调用子应用暴露出来的方法。但这通常不推荐作为主要的通信方式，因为它增加了耦合度。
- URL 参数或 History State： 对于与路由相关的通信，可以通过 URL 参数或 HTML5 History API 的 state 来传递信息，无界通常会处理这些信息的同步。
推荐使用事件总线作为主要的通信手段，因为它能够更好地解耦主应用和子应用，提高系统的可维护性。
如何将一个子应用集成到主应用？
将一个子应用集成到无界主应用通常涉及以下步骤：
-
安装无界库：
在主应用的项目中安装无界相关的 npm 包：
npm install wujie-vue wujie --save（注意：
wujie-vue,wujie-react等是针对特定框架的辅助库，核心是wujie） -
在主应用中引入并配置无界：
在主应用的入口文件或需要渲染子应用的地方引入无界。
import WujieVue from 'wujie-vue';
import { appManager } from 'wujie';
// 在 Vue 应用中注册组件或插件
createApp(App).use(WujieVue).mount('#app');
// 或直接使用核心 API
appManager.startApp({...}); -
准备子应用：
子应用需要是一个可以独立运行的 Web 应用，并且可以通过一个 URL 访问到其入口文件（通常是 index.html）。子应用可能需要进行一些简单的修改，例如暴露生命周期钩子函数（如果需要无界管理其生命周期）或者接收主应用传递的 props。
生命周期： 无界允许子应用暴露诸如
bootstrap,mount,unmount等生命周期函数，主应用可以通过配置告知无界在何时调用这些函数来控制子应用的初始化、挂载和卸载过程。子应用通常需要在其入口文件中将这些函数挂载到 window 对象上供无界调用。例如，在子应用的入口文件 (main.js) 中：
let instance = null;
window.__WUJIE_BOOTSTRAP__ = () => {
console.log('子应用 bootstrap');
};
window.__WUJIE_MOUNT__ = () => {
console.log('子应用 mount');
instance = createApp(App).mount('#app'); // 挂载子应用
};
window.__WUJIE_UNMOUNT__ = () => {
console.log('子应用 unmount');
instance.$destroy(); // 销毁子应用实例
};
// 可选：接收主应用 props
console.log('Props from host:', window.__WUJIE?.props); -
在主应用中渲染子应用：
在主应用的模板或组件中，使用无界提供的组件（例如 `wujie-vue` 提供的 `
` 组件）或调用核心 API 来渲染子应用。 使用组件方式 (Vue)：
<template>
<WujieVue name="my-child-app" url="http://localhost:8081/" :sync="true" :props="childProps"></WujieVue>
</template>
<script>
export default {
data() {
return {
childProps: {
message: 'Hello from Host'
}
};
}
};
</script>使用核心 API 方式：
appManager.startApp({
name: 'my-child-app-api',
url: 'http://localhost:8082/',
el: '#child-app-container', // 指定渲染容器
sync: true,
props: { apiData: {} },
// 更多配置项...
}); -
配置选项说明：
name: 子应用的唯一名称，用于标识。url: 子应用的入口 URL (index.html)。el: 子应用挂载的 DOM 容器（使用核心 API 时）。sync: 是否同步主应用和子应用的路由状态。props: 传递给子应用的数据对象。attrs: 传递给 iframe 元素的属性。execScripts: 控制脚本的执行方式。- 生命周期钩子：如
beforeLoad,afterLoad,beforeMount,afterMount,beforeUnmount,afterUnmount,activated,deactivated,error等，用于在主应用中监听子应用的状态变化。
完成这些步骤后，主应用在渲染对应组件或调用 API 时，就会加载并显示指定的子应用内容。
无界如何处理路由同步？
路由同步是微前端中一个常见且重要的问题，它涉及到：
- 当用户在子应用内部进行路由跳转时，主应用的 URL 如何同步更新，以便刷新页面或分享链接时能够恢复到正确的状态？
- 当用户在主应用中通过改变 URL（例如，使用浏览器前进/后退按钮）来访问子应用路由时，子应用如何响应并导航到对应的页面？
无界提供了 路由同步机制 来解决这个问题。通常通过配置项启用：
在配置子应用时设置
sync属性：<WujieVue name="my-child-app" url="http://localhost:8081/" :sync="true"></WujieVue>
当 sync 属性设置为 true 时，无界会：
-
监听子应用的路由变化： 无界会在 iframe 内部劫持子应用的 History API (
pushState,replaceState) 或监听 hash 变化。 -
同步到主应用 URL： 当子应用的路由发生变化时，无界会将子应用的路由信息（通常是路径和查询参数）同步到主应用的 URL 中，通常是添加到主应用 URL 的 hash 或 path 中（具体方式可能与主应用的路由模式有关）。例如，如果子应用的路径是
/child/about，主应用的 URL 可能是#/child/about或/main#/child/about。 - 监听主应用 URL 变化： 同时，无界也会监听主应用 URL 的变化，特别是当 URL 中包含某个子应用的路由信息时。
- 同步到子应用路由： 当主应用 URL 变化反映了子应用的导航意图时（例如，用户点击了浏览器后退按钮，主应用 URL 回到了子应用的某个状态），无界会将对应的路由信息同步回子应用内部，触发子应用的路由导航。
这种双向同步确保了用户在主应用和子应用之间导航时，浏览器的 URL 状态始终是正确的，并且后退、前进、刷新等操作能够按照预期工作。在使用路由同步时，需要注意主应用和子应用之间的路由前缀配置，避免冲突，并确保无界能够正确解析和匹配路由。
无界如何管理共享资源和样式冲突？
管理共享资源（如公共库）和避免样式冲突是微前端实践中的两大挑战。无界在这方面提供了解决方案：
样式冲突（CSS Isolation）：
iframe 天然提供了强大的样式隔离能力。子应用在 iframe 中加载的 CSS 规则默认只作用于该 iframe 内部的 DOM 元素，不会影响到主应用或其他 iframe 中的样式。无界利用了这一特性，这是其样式隔离的主要手段。
此外，无界可能还支持结合或利用：
- Shadow DOM： 在 iframe 内部的特定容器中使用 Shadow DOM，进一步增强隔离性，确保子应用组件内部的样式不会影响到外部。
- 样式前缀/后处理： 虽然 iframe 隔离性很高，但在极少数需要样式穿透或特定场景下，无界也可能提供额外的配置或建议，例如通过给子应用样式添加特定的前缀，或者在构建阶段进行后处理。但通常情况下，iframe 的原生隔离已经足够解决大多数样式冲突问题。
相比于非 iframe 方案需要大量手动配置 CSS modules、Scoped CSS 或运行时沙箱来限制样式作用域，无界在样式隔离方面具有显著的便利性和鲁棒性。
共享资源 (JS Dependencies)：
共享 JavaScript 库（如 Vue, React, lodash 等）是提高性能和减少包体积的重要手段。在无界架构下，由于子应用运行在独立的 iframe 中，它们与主应用拥有不同的全局环境。直接在主应用中加载的库不会自动被子应用共享。
无界提供了几种处理共享资源的方式：
- Externalize（外部化）： 在子应用的构建配置中，将需要共享的库设置为外部依赖 (external)。然后，在主应用或无界加载子应用之前，确保这些共享库已经被加载到主应用的全局环境中（或者通过无界的配置，让无界将这些库注入到子应用的 iframe 环境中）。无界提供了配置项来指定哪些脚本应该在子应用加载前优先注入。
- 动态注入： 无界可以在加载子应用时，根据配置动态地将某些全局变量或库实例从主应用的环境传递或代理到子应用的 iframe 环境中。
- 统一构建/CDN： 将共享库发布到 CDN，主应用和子应用都通过 CDN 加载。尽管是两次加载，但利用浏览器缓存也能提高效率。更高级的方式是无界协调加载，避免重复下载。
处理共享资源需要主应用和子应用的协同配置。通常推荐将大型、稳定的第三方库进行外部化处理，并通过无界进行协调加载，以达到最佳效果。这方面不如 Module Federation 等方案在 JS 模块共享上自动化程度高，需要一些手动的配置和规划。
如何开始使用无界微前端？有哪些实践注意事项？
如何开始使用：
- 明确需求： 分析现有应用结构和痛点，确定是否适合引入微前端以及无界是否是最合适的选择（考虑 iframe 隔离的利弊）。
- 技术选型确认： 确认主应用和计划集成的子应用技术栈，以及无界对这些技术栈的兼容性（虽然通常很高）。
- 安装与引入： 在主应用项目中按照文档安装无界库。
- 准备子应用： 将计划集成的应用构建为可独立访问的 Web 应用，并根据需要暴露生命周期钩子。确保子应用的开发服务器或构建产物可以通过网络访问。
- 主应用配置与渲染： 在主应用中选择合适的集成方式（组件或 API），配置子应用的名称、URL、路由同步、props 等。
- 开发与调试： 同时运行主应用和子应用的开发服务器。利用浏览器开发者工具，特别注意 iframe 内部的调试。无界通常会提供一些辅助调试工具或面板。
- 构建与部署： 配置主应用和子应用的构建流程，确保子应用的静态资源能够正确地部署并被主应用通过 URL 访问到。
详细的步骤和 API 使用请参考无界的官方文档，它是最准确和全面的指南。
实践注意事项：
- 跨域问题： 主应用和子应用部署在不同的域或端口时会存在跨域问题。需要配置 CORS 或者使用代理解决子应用资源加载和接口请求的跨域。
- 性能考量： 尽管无界有优化，但创建和管理 iframe 仍然有一定开销。子应用数量不宜过多；考虑使用懒加载或预加载优化初次加载性能。监控内存使用，特别是当子应用频繁切换或不完全卸载时。
- 内存泄漏： 确保在子应用卸载时，清除所有的事件监听、定时器、DOM 引用等，避免内存泄漏。利用无界提供的 unmount 生命周期钩子来执行清理工作至关重要。
- 状态管理： 跨子应用共享状态是一个复杂问题。不建议直接共享全局 Store。可以考虑将共享状态提升到主应用管理，并通过 Props 或 Event Bus 同步给子应用；或者使用独立的状态管理服务，主应用和子应用都通过 API 调用来获取和更新状态。
- 公共依赖管理： 合理规划和配置公共依赖的加载策略（外部化、注入），避免重复加载和版本冲突。
- 用户体验： 处理好子应用的加载中状态、错误状态。确保路由同步的流畅性，特别是浏览器前进后退按钮的行为。考虑微前端环境下的统一 loading、权限控制、全局异常捕获等。
- iframe 的限制： 了解 iframe 本身的限制，例如访问父级/子级 DOM 受到同源策略限制（除非有特殊通信手段）、对话框（如 alert, confirm）会在 iframe 内部弹出等。
- SEO 与可访问性： 基于 iframe 的内容对搜索引擎的抓取和无障碍访问可能不如直接渲染在主应用 DOM 中的内容友好，需要额外的优化手段（如服务器端渲染或预渲染，如果这对应用很重要）。
总的来说，无界微前端以其基于 iframe 的强隔离和高易用性，为解决大型前端应用的复杂性提供了一个有力的选择，特别适合需要快速集成现有应用或处理多技术栈并存的场景。理解其核心机制和掌握实践注意事项，能够帮助开发者更有效地利用无界构建健壮、可维护的微前端应用。
