1. 项目概述一个轻量级、可扩展的微前端架构方案最近在梳理团队前端架构时又翻出了mattmezza/mpa这个项目。它不是那种动辄几千星、社区活跃度爆表的明星项目但在特定场景下它提供了一种极其务实、甚至可以说是“返璞归真”的微前端实现思路。如果你正被单页面应用SPA日益膨胀的体积、复杂的构建流程和首屏性能问题所困扰同时又对主流微前端框架如single-spa、qiankun的复杂性和侵入性感到犹豫那么mattmezza/mpa所倡导的“基于多页应用MPA的微前端”理念或许能给你带来一些新的启发。简单来说mattmezza/mpa不是一个功能完备的框架而是一个架构蓝图和工具集。它的核心思想是为什么不回归 Web 最原生的多页应用模式来实现前端应用的解耦与集成呢每个微应用或称为“子应用”本身就是一个独立部署、独立开发、技术栈任选的完整 HTML 页面。这些页面通过一个轻量的“胶水层”进行协调在用户无感知的情况下实现应用间的切换和状态共享。它不依赖 iframe不要求子应用改造为生命周期钩子其复杂度远低于基于 SPA 的微前端方案却能解决团队协同、技术栈异构、独立部署等核心痛点。这个项目特别适合那些业务模块相对独立、交互以页面跳转为主、对应用间深度耦合要求不高的中后台系统、门户网站或内部平台。对于前端团队规模不大、但需要快速整合遗留系统比如用 jQuery 写的管理页面和现代框架如 React、Vue新功能的场景mattmezza/mpa提供了一条平滑的演进路径。接下来我将深入拆解这套架构的设计思路、核心实现、实操要点以及我趟过的一些坑。1.1 核心需求与场景解析为什么我们需要考虑 MPA 模式的微前端这源于几个在传统 SPA 微前端方案中不那么“优雅”解决的痛点。首当其冲的是性能与复杂度。一个集成了多个子应用的主 SPA 应用其初始 JavaScript 包体积可能非常庞大即使做了代码分割运行时协调各个子应用生命周期的框架本身也有开销。而mattmezza/mpa的方案下用户访问哪个页面才加载哪个页面所需的资源做到了真正的按需加载首屏时间只取决于当前页面没有额外的框架运行时负担。其次是技术栈的绝对自由与低侵入性。像qiankun这样的方案虽然支持多技术栈但通常要求子应用暴露特定的生命周期函数bootstrap,mount,unmount并对 webpack 配置进行改造。这对于一些陈旧的、非现代构建流程的应用例如纯后端渲染的页面、基于 Gulp 构建的项目来说改造成本很高。而mattmezza/mpa模式下子应用就是一个完整的、可独立运行的 HTML 页面它不需要知道会被谁集成只要能被浏览器正常渲染即可。这意味着你可以无缝集成一个十年前的 jQuery 页面、一个 Vue CLI 创建的应用、一个 Create React App 生成的项目甚至是一个简单的静态页面。再者是部署与开发的完全独立。每个子应用拥有自己独立的代码仓库、构建流水线和部署域名/路径。团队可以按照业务域进行划分每个团队对自己的子应用拥有完整的控制权发布节奏互不影响。主应用或称“壳”应用只负责路由调度和简单的共享状态管理本身非常轻量稳定性极高。注意这种方案的“代价”是放弃了 SPA 的无刷新页面切换体验。页面跳转会带来真正的浏览器导航即会有白屏时间。因此它最适合业务模块边界清晰、页面跳转后上下文切换自然的系统例如从“用户管理”跳转到“订单管理”。如果您的应用是类似 Figma 或 Notion 这样的强交互、单工作空间产品那么传统的 SPA 或基于 SPA 的微前端仍是更佳选择。2. 架构设计与核心思路拆解mattmezza/mpa项目的核心在于一套清晰、简单的约定和少量的运行时脚本。我们可以将其架构分解为三个核心部分主应用Shell、子应用Micro App和通信桥梁Bridge。2.1 主应用Shell的角色与职责主应用是整个微前端架构的“外壳”和“调度中心”。它通常是一个极其简单的页面只包含最基础的布局框架如顶部导航栏、侧边菜单和用于加载子应用内容的容器如一个div id”app-container”。它的核心职责有三点路由映射与拦截监听浏览器的 URL 变化通常是hash路由或利用History API进行细粒度控制根据预设的规则将不同的路径映射到对应的子应用入口地址。子应用页面加载根据路由映射的结果动态地将子应用的完整 HTML 页面加载到指定的容器中。这里的关键技术点是fetch子应用的 HTML然后提取出body内的主要内容或者更优雅地让子应用提供一份仅包含核心内容的“片段”。提供全局共享服务初始化并管理跨子应用的共享状态、用户身份信息、通用工具函数等。这些服务通过一个全局的window.__MPA_SHELL__对象或类似机制暴露给所有子应用。主应用本身不应该包含复杂的业务逻辑它的稳定性是重中之重。在实践中我通常会用最少的依赖比如就一个Vue或React来管理导航状态来构建它甚至可以考虑用原生 JavaScript 实现。2.2 子应用Micro App的构建规范子应用是独立的、功能完整的 Web 应用。为了能被主应用顺利集成它需要遵循一些简单的约定入口文件清晰每个子应用需要提供一个主入口 HTML 文件的 URL例如https://app-a.example.com/index.html。资源路径处理关键这是最容易出问题的地方。子应用中的所有静态资源JS、CSS、图片、字体必须使用绝对路径或相对于域名的路径。避免使用相对于当前 HTML 文件的相对路径如./static/js/app.js因为当子应用的 HTML 被嵌入主应用容器后浏览器解析相对路径的基准会变成主应用的 URL导致资源加载失败。解决方案在构建时将publicPath设置为完整的域名路径例如https://cdn.your-app.com/或者使用/开头的绝对路径并确保主应用和子应用部署在同一个域名下通过反向代理区分路径。样式隔离由于是直接注入 HTML 片段子应用的 CSS 可能会污染全局样式。建议子应用采用 CSS Modules、Scoped CSSVue或 CSS-in-JS 等方案进行样式隔离。如果做不到一个朴素的方案是为子应用根元素添加一个特定的>// 在主应用中初始化 window.__MPA_EVENT_BUS__ new EventTarget(); // 在子应用A中发送事件 window.__MPA_EVENT_BUS__.dispatchEvent(new CustomEvent(user-logged-in, { detail: { userId: 123 } })); // 在子应用B中监听事件 window.__MPA_EVENT_BUS__.addEventListener(user-logged-in, (event) { console.log(收到用户登录事件:, event.detail.userId); });共享状态管理对于需要跨应用共享的简单状态如用户Token、主题偏好可以存放在window.__MPA_SHARED_STATE__这样一个全局对象中。对于复杂状态建议由主应用通过 Props 的方式在加载子应用时注入或者利用上述事件总线进行状态同步。URL 作为通信媒介页面跳转本身可以通过 URL 传递参数这是一种天然、直接的通信方式。主应用的路由解析器可以将 URL 中的查询参数解析后作为“初始状态”传递给目标子应用。这种通信方式足够轻量但也要求开发者有良好的约定避免事件名冲突和循环触发。3. 核心实现细节与实操要点理解了架构我们来看看如何一步步实现它。我将以一套典型的基于hash路由的实现为例拆解关键代码。3.1 主应用路由加载器的实现主应用的核心是一个路由加载器。它监听hashchange事件根据hash值决定加载哪个子应用。// shell-app/src/router.js class MpaRouter { constructor(config) { // config 格式 { ‘/app-a‘: ‘https://app-a.domain.com‘, ‘/app-b‘: ‘https://app-b.domain.com‘ } this.appMap config; this.container document.getElementById(app-container); this.currentAppUrl null; this.init(); } init() { // 监听 hash 变化 window.addEventListener(hashchange, this.handleRouteChange.bind(this)); // 初始加载 this.handleRouteChange(); } handleRouteChange() { const hash window.location.hash.slice(1) || /; // 去掉 ‘#‘ const matchedRule Object.keys(this.appMap).find(rule hash.startsWith(rule)); if (matchedRule) { const appBaseUrl this.appMap[matchedRule]; // 提取子应用路径例如 hash‘/app-a/user/1‘, rule‘/app-a‘, 则 appPath‘/user/1‘ const appPath hash.replace(matchedRule, ) || /; const appFullUrl ${appBaseUrl}${appPath}; this.loadApp(appFullUrl); } else { // 未匹配到任何子应用可以加载一个默认页面或404 this.container.innerHTML h2页面未找到/h2; } } async loadApp(url) { if (this.currentAppUrl url) return; // 防止重复加载 console.log(正在加载子应用: ${url}); this.container.innerHTML div classloading加载中.../div; try { const response await fetch(url); if (!response.ok) throw new Error(HTTP ${response.status}); const htmlText await response.text(); // 使用 DOMParser 解析 HTML提取 body 内容 const parser new DOMParser(); const doc parser.parseFromString(htmlText, text/html); // 清理容器 this.container.innerHTML ; // 将子应用 body 内的所有节点移动到容器中 // 注意这里直接移动了所有节点包括 scripts。 // 更安全的做法是只移动内容并单独处理 script 标签见下文注意事项 Array.from(doc.body.children).forEach(child { this.container.appendChild(child.cloneNode(true)); // 使用 cloneNode }); // **关键执行子应用带来的内联脚本** this.executeScripts(this.container); this.currentAppUrl url; console.log(子应用加载完成: ${url}); } catch (error) { console.error(加载子应用失败: ${url}, error); this.container.innerHTML div classerror加载失败请刷新重试/div; } } executeScripts(container) { const scripts container.querySelectorAll(script); scripts.forEach(oldScript { const newScript document.createElement(script); // 复制所有属性 Array.from(oldScript.attributes).forEach(attr { newScript.setAttribute(attr.name, attr.value); }); // 复制内联脚本内容 if (oldScript.textContent) { newScript.textContent oldScript.textContent; } // 替换旧脚本并执行 oldScript.parentNode.replaceChild(newScript, oldScript); }); } } // 初始化 const router new MpaRouter({ /user-management: https://user-app.example.com, /order-center: https://order-app.example.com, /legacy-report: https://legacy.example.com/reports });实操心得executeScripts函数至关重要。通过fetch获取的 HTML 中的script标签在被插入 DOM 时不会自动执行。我们必须手动创建新的 script 元素来替换它们才能触发脚本执行。同时要确保src为外部资源的脚本也能正确加载这依赖于前面提到的资源路径必须正确。3.2 子应用的构建配置要点以一个使用 Webpack 的 Vue.js 子应用为例关键的配置在于publicPath和可能需要的输出格式调整。// vue-app/vue.config.js const { defineConfig } require(vue/cli-service); module.exports defineConfig({ // 关键设置正确的 publicPath // 假设子应用将独立部署在 https://assets.mycompany.com/user-app/ publicPath: process.env.NODE_ENV production ? https://assets.mycompany.com/user-app/ // CDN或独立域名 : /, // 开发环境 // 确保资源文件名包含哈希利于缓存和更新 filenameHashing: true, // 如果你希望主应用能像加载普通页面一样加载可以输出一个完整的HTML。 // 但更优的做法是提供一个“片段”入口主应用只加载这个片段。 // 这需要额外的配置例如使用一个特殊的入口文件只导出组件而非完整应用。 })更高级的做法是提供“应用片段”。我们可以构建两个入口一个用于独立运行的完整应用app.html另一个是仅包含应用根组件渲染逻辑的 JavaScript 片段fragment.js。主应用加载这个片段并执行传入容器元素。这种方式资源控制更精细但子应用改造量稍大。3.3 样式与脚本隔离的实践样式隔离对于 Vue 应用style scoped是天然的隔离方案。对于 React可以使用 CSS Modules。如果子应用使用了全局 CSS 库如 Bootstrap一个折中方案是在主应用的布局中为子应用容器包裹一个具有特定类名或 ID 的 div然后让子应用的 CSS 规则都嵌套在这个选择器下。但这需要构建工具支持 CSS 重写实现成本较高。脚本隔离确保子应用的入口文件是模块化的。对于 Webpack 打包的应用默认输出就是一个 IIFE 或模块通常不会污染全局。但要特别注意避免直接向window对象挂载大量属性。如果必须挂载如某些 SDK使用具有命名空间的名称例如window.__UserApp_SDK。在应用“卸载”时虽然对 MPA 来说是页面跳转但主应用可能会清理容器清理定时器、事件监听器、取消网络请求等。这需要子应用暴露一个清理函数并由主应用在加载新页面前调用。// 子应用入口 (fragment.js) (function() { let cleanupHandlers []; function mount(container, props) { // 渲染逻辑... const resizeHandler () console.log(resize); window.addEventListener(resize, resizeHandler); // 注册清理函数 cleanupHandlers.push(() { window.removeEventListener(resize, resizeHandler); }); } function unmount() { // 执行所有清理操作 cleanupHandlers.forEach(handler handler()); cleanupHandlers []; } // 暴露给主应用调用的接口 window.__MyMicroApp { mount, unmount }; })();在主应用加载新子应用前可以尝试调用window.__MyMicroApp?.unmount()进行清理。4. 部署与运维方案MPA 微前端的部署相对简单但也需要规划。4.1 独立部署与域名规划最理想的模式是每个子应用拥有独立的二级域名或路径并支持 HTTPS。方案A独立域名user-app.example.com,order-app.example.com。优势是隔离彻底Cookie 可以按域名隔离。缺点是可能遇到跨域问题需要配置 CORS且域名较多。方案B路径区分主应用在www.example.com子应用部署在www.example.com/user-app/,www.example.com/order-app/。通过 Nginx 等反向代理将不同路径的请求转发到不同的后端服务或静态资源服务器。这种方式避免了跨域更简洁。反向代理配置示例 (Nginx)server { listen 80; server_name www.example.com; location / { # 主应用静态资源 root /path/to/shell-app/dist; try_files $uri $uri/ /index.html; } location ^~ /user-app/ { # 代理到用户子应用的服务或静态目录 alias /path/to/user-app/dist/; try_files $uri $uri/ /index.html; # 或者反向代理到子应用服务器 # proxy_pass http://localhost:3001; } location ^~ /order-app/ { alias /path/to/order-app/dist/; try_files $uri $uri/ /index.html; } }4.2 版本更新与灰度发布由于子应用完全独立每个团队可以自行决定发布节奏。主应用通过子应用的入口 URL 来加载它。一个常见的实践是子应用的入口 HTML 文件如index.html本身是稳定的但其内部引用的 JavaScript 和 CSS 文件是带哈希值的。这样更新子应用只需部署新的静态资源并更新 HTML 中引用的资源路径即可。主应用无需任何改动。为了实现更可控的灰度可以在主应用的路由映射配置中做文章。例如根据用户 ID 或特征标志Feature Flag将部分用户的请求路由到新版本的子应用 URL如一个灰度环境的地址。5. 常见问题、排查技巧与避坑指南在实际落地过程中我遇到了不少问题这里总结出最典型的几个及其解决方案。5.1 资源加载 404 错误这是最常见的问题。症状是子应用的 JS、CSS、图片等资源无法加载。排查步骤打开浏览器开发者工具的 Network 面板查看失败资源的完整 URL。检查这个 URL 是否正确拼接。通常问题在于资源路径是相对路径被浏览器基于主应用的 URL如https://shell.com/#/app-a进行解析最终指向了错误的位置。解决方案确保子应用构建的publicPath配置正确。生产环境应设置为完整的绝对 URL 或正确的根路径。对于图片等资源在代码中引用时使用模块导入或确保路径以publicPath为基准。在主应用加载子应用 HTML 后可以写一个脚本遍历所有link[href],script[src],img[src]等标签检查并修复资源路径。但这只是补救措施根治还需在子应用构建时完成。5.2 JavaScript 执行错误或冲突问题子应用脚本未执行或变量冲突导致功能异常。排查查看 Console 面板是否有语法错误、变量未定义或执行错误。解决方案确认主应用的executeScripts逻辑正确特别是对于有src的外部脚本新创建的 script 标签要添加到document.body而非容器内并监听其onload/onerror事件。检查子应用的 JS 是否使用了严格模式‘use strict‘;并确保没有定义全局同名变量。利用浏览器开发者工具的 Sources 面板给子应用脚本添加断点逐步调试。5.3 样式污染与覆盖问题子应用的样式影响了主应用的导航栏或者多个子应用的样式相互干扰。排查使用 Elements 面板检查元素看最终生效的 CSS 规则来自哪个样式表。解决方案首选方案在子应用中强制使用 CSS 隔离技术Scoped CSS, CSS Modules。次选方案在主应用加载子应用内容前为容器添加一个唯一的>特性mattmezza/mpa(MPA模式)single-spa/qiankun(SPA模式)iframe模块联邦 (Module Federation)技术栈限制无限制任何能生成HTML页面的技术都行通常需支持生命周期钩子对老旧应用改造有成本无限制需使用 Webpack 5且应用间耦合度较高隔离性中等需注意样式/脚本污染高支持沙箱极高完全隔离低共享模块依赖版本需协调开发体验子应用独立开发、构建、部署体验好需要复杂的配置和改造对主应用依赖较强差调试困难通信复杂好但配置复杂对构建工具链要求高性能首屏性能好切换有白屏首屏框架开销大切换流畅差每个iframe都是完整上下文开销大构建时优化运行时性能好通信复杂度简单事件/全局状态复杂需通过框架提供的API复杂且受限postMessage简单模块导入适用场景页面级聚合、中后台、门户、整合遗留系统追求单页体验的复杂应用、交互密集型产品完全隔离的第三方页面如地图、支付应用间高度依赖、希望共享代码库的现代Web应用选型建议如果你的系统业务模块分明以页面跳转为主要交互且包含多个不同技术栈或历史包袱重的应用希望用最小成本实现整合和独立部署那么mattmezza/mpa的思路是一个非常务实且高效的选择。如果你追求极致的单页应用体验希望应用间切换如丝般顺滑且所有子应用都基于现代框架React/Vue/Angular开发愿意接受一定的框架复杂性和改造成本那么qiankun这类基于 SPA 的微前端框架更合适。iframe适用于需要绝对安全隔离的场景如嵌入完全不受控的第三方页面。模块联邦更适合一个技术栈统一、希望深度共享组件和逻辑的“巨应用”拆分解耦。在我经历的一个项目中我们需要将一个 AngularJS 的老旧后台、一个 jQuery 的报表系统和两个新的 React 功能模块整合进统一的管理平台。采用mattmezza/mpa的方案我们只花了不到两周就完成了架构搭建和初步集成各个团队几乎零改造成本。虽然页面切换时有短暂的加载感但业务方完全能够接受因为换来了开发部署的极大自由度和系统的可维护性。这个选择的关键在于清晰地认识到我们最需要解决的是“整合”与“自治”的矛盾而非“无缝体验”。
基于MPA的微前端架构：轻量级、低侵入的前端应用集成方案
1. 项目概述一个轻量级、可扩展的微前端架构方案最近在梳理团队前端架构时又翻出了mattmezza/mpa这个项目。它不是那种动辄几千星、社区活跃度爆表的明星项目但在特定场景下它提供了一种极其务实、甚至可以说是“返璞归真”的微前端实现思路。如果你正被单页面应用SPA日益膨胀的体积、复杂的构建流程和首屏性能问题所困扰同时又对主流微前端框架如single-spa、qiankun的复杂性和侵入性感到犹豫那么mattmezza/mpa所倡导的“基于多页应用MPA的微前端”理念或许能给你带来一些新的启发。简单来说mattmezza/mpa不是一个功能完备的框架而是一个架构蓝图和工具集。它的核心思想是为什么不回归 Web 最原生的多页应用模式来实现前端应用的解耦与集成呢每个微应用或称为“子应用”本身就是一个独立部署、独立开发、技术栈任选的完整 HTML 页面。这些页面通过一个轻量的“胶水层”进行协调在用户无感知的情况下实现应用间的切换和状态共享。它不依赖 iframe不要求子应用改造为生命周期钩子其复杂度远低于基于 SPA 的微前端方案却能解决团队协同、技术栈异构、独立部署等核心痛点。这个项目特别适合那些业务模块相对独立、交互以页面跳转为主、对应用间深度耦合要求不高的中后台系统、门户网站或内部平台。对于前端团队规模不大、但需要快速整合遗留系统比如用 jQuery 写的管理页面和现代框架如 React、Vue新功能的场景mattmezza/mpa提供了一条平滑的演进路径。接下来我将深入拆解这套架构的设计思路、核心实现、实操要点以及我趟过的一些坑。1.1 核心需求与场景解析为什么我们需要考虑 MPA 模式的微前端这源于几个在传统 SPA 微前端方案中不那么“优雅”解决的痛点。首当其冲的是性能与复杂度。一个集成了多个子应用的主 SPA 应用其初始 JavaScript 包体积可能非常庞大即使做了代码分割运行时协调各个子应用生命周期的框架本身也有开销。而mattmezza/mpa的方案下用户访问哪个页面才加载哪个页面所需的资源做到了真正的按需加载首屏时间只取决于当前页面没有额外的框架运行时负担。其次是技术栈的绝对自由与低侵入性。像qiankun这样的方案虽然支持多技术栈但通常要求子应用暴露特定的生命周期函数bootstrap,mount,unmount并对 webpack 配置进行改造。这对于一些陈旧的、非现代构建流程的应用例如纯后端渲染的页面、基于 Gulp 构建的项目来说改造成本很高。而mattmezza/mpa模式下子应用就是一个完整的、可独立运行的 HTML 页面它不需要知道会被谁集成只要能被浏览器正常渲染即可。这意味着你可以无缝集成一个十年前的 jQuery 页面、一个 Vue CLI 创建的应用、一个 Create React App 生成的项目甚至是一个简单的静态页面。再者是部署与开发的完全独立。每个子应用拥有自己独立的代码仓库、构建流水线和部署域名/路径。团队可以按照业务域进行划分每个团队对自己的子应用拥有完整的控制权发布节奏互不影响。主应用或称“壳”应用只负责路由调度和简单的共享状态管理本身非常轻量稳定性极高。注意这种方案的“代价”是放弃了 SPA 的无刷新页面切换体验。页面跳转会带来真正的浏览器导航即会有白屏时间。因此它最适合业务模块边界清晰、页面跳转后上下文切换自然的系统例如从“用户管理”跳转到“订单管理”。如果您的应用是类似 Figma 或 Notion 这样的强交互、单工作空间产品那么传统的 SPA 或基于 SPA 的微前端仍是更佳选择。2. 架构设计与核心思路拆解mattmezza/mpa项目的核心在于一套清晰、简单的约定和少量的运行时脚本。我们可以将其架构分解为三个核心部分主应用Shell、子应用Micro App和通信桥梁Bridge。2.1 主应用Shell的角色与职责主应用是整个微前端架构的“外壳”和“调度中心”。它通常是一个极其简单的页面只包含最基础的布局框架如顶部导航栏、侧边菜单和用于加载子应用内容的容器如一个div id”app-container”。它的核心职责有三点路由映射与拦截监听浏览器的 URL 变化通常是hash路由或利用History API进行细粒度控制根据预设的规则将不同的路径映射到对应的子应用入口地址。子应用页面加载根据路由映射的结果动态地将子应用的完整 HTML 页面加载到指定的容器中。这里的关键技术点是fetch子应用的 HTML然后提取出body内的主要内容或者更优雅地让子应用提供一份仅包含核心内容的“片段”。提供全局共享服务初始化并管理跨子应用的共享状态、用户身份信息、通用工具函数等。这些服务通过一个全局的window.__MPA_SHELL__对象或类似机制暴露给所有子应用。主应用本身不应该包含复杂的业务逻辑它的稳定性是重中之重。在实践中我通常会用最少的依赖比如就一个Vue或React来管理导航状态来构建它甚至可以考虑用原生 JavaScript 实现。2.2 子应用Micro App的构建规范子应用是独立的、功能完整的 Web 应用。为了能被主应用顺利集成它需要遵循一些简单的约定入口文件清晰每个子应用需要提供一个主入口 HTML 文件的 URL例如https://app-a.example.com/index.html。资源路径处理关键这是最容易出问题的地方。子应用中的所有静态资源JS、CSS、图片、字体必须使用绝对路径或相对于域名的路径。避免使用相对于当前 HTML 文件的相对路径如./static/js/app.js因为当子应用的 HTML 被嵌入主应用容器后浏览器解析相对路径的基准会变成主应用的 URL导致资源加载失败。解决方案在构建时将publicPath设置为完整的域名路径例如https://cdn.your-app.com/或者使用/开头的绝对路径并确保主应用和子应用部署在同一个域名下通过反向代理区分路径。样式隔离由于是直接注入 HTML 片段子应用的 CSS 可能会污染全局样式。建议子应用采用 CSS Modules、Scoped CSSVue或 CSS-in-JS 等方案进行样式隔离。如果做不到一个朴素的方案是为子应用根元素添加一个特定的>// 在主应用中初始化 window.__MPA_EVENT_BUS__ new EventTarget(); // 在子应用A中发送事件 window.__MPA_EVENT_BUS__.dispatchEvent(new CustomEvent(user-logged-in, { detail: { userId: 123 } })); // 在子应用B中监听事件 window.__MPA_EVENT_BUS__.addEventListener(user-logged-in, (event) { console.log(收到用户登录事件:, event.detail.userId); });共享状态管理对于需要跨应用共享的简单状态如用户Token、主题偏好可以存放在window.__MPA_SHARED_STATE__这样一个全局对象中。对于复杂状态建议由主应用通过 Props 的方式在加载子应用时注入或者利用上述事件总线进行状态同步。URL 作为通信媒介页面跳转本身可以通过 URL 传递参数这是一种天然、直接的通信方式。主应用的路由解析器可以将 URL 中的查询参数解析后作为“初始状态”传递给目标子应用。这种通信方式足够轻量但也要求开发者有良好的约定避免事件名冲突和循环触发。3. 核心实现细节与实操要点理解了架构我们来看看如何一步步实现它。我将以一套典型的基于hash路由的实现为例拆解关键代码。3.1 主应用路由加载器的实现主应用的核心是一个路由加载器。它监听hashchange事件根据hash值决定加载哪个子应用。// shell-app/src/router.js class MpaRouter { constructor(config) { // config 格式 { ‘/app-a‘: ‘https://app-a.domain.com‘, ‘/app-b‘: ‘https://app-b.domain.com‘ } this.appMap config; this.container document.getElementById(app-container); this.currentAppUrl null; this.init(); } init() { // 监听 hash 变化 window.addEventListener(hashchange, this.handleRouteChange.bind(this)); // 初始加载 this.handleRouteChange(); } handleRouteChange() { const hash window.location.hash.slice(1) || /; // 去掉 ‘#‘ const matchedRule Object.keys(this.appMap).find(rule hash.startsWith(rule)); if (matchedRule) { const appBaseUrl this.appMap[matchedRule]; // 提取子应用路径例如 hash‘/app-a/user/1‘, rule‘/app-a‘, 则 appPath‘/user/1‘ const appPath hash.replace(matchedRule, ) || /; const appFullUrl ${appBaseUrl}${appPath}; this.loadApp(appFullUrl); } else { // 未匹配到任何子应用可以加载一个默认页面或404 this.container.innerHTML h2页面未找到/h2; } } async loadApp(url) { if (this.currentAppUrl url) return; // 防止重复加载 console.log(正在加载子应用: ${url}); this.container.innerHTML div classloading加载中.../div; try { const response await fetch(url); if (!response.ok) throw new Error(HTTP ${response.status}); const htmlText await response.text(); // 使用 DOMParser 解析 HTML提取 body 内容 const parser new DOMParser(); const doc parser.parseFromString(htmlText, text/html); // 清理容器 this.container.innerHTML ; // 将子应用 body 内的所有节点移动到容器中 // 注意这里直接移动了所有节点包括 scripts。 // 更安全的做法是只移动内容并单独处理 script 标签见下文注意事项 Array.from(doc.body.children).forEach(child { this.container.appendChild(child.cloneNode(true)); // 使用 cloneNode }); // **关键执行子应用带来的内联脚本** this.executeScripts(this.container); this.currentAppUrl url; console.log(子应用加载完成: ${url}); } catch (error) { console.error(加载子应用失败: ${url}, error); this.container.innerHTML div classerror加载失败请刷新重试/div; } } executeScripts(container) { const scripts container.querySelectorAll(script); scripts.forEach(oldScript { const newScript document.createElement(script); // 复制所有属性 Array.from(oldScript.attributes).forEach(attr { newScript.setAttribute(attr.name, attr.value); }); // 复制内联脚本内容 if (oldScript.textContent) { newScript.textContent oldScript.textContent; } // 替换旧脚本并执行 oldScript.parentNode.replaceChild(newScript, oldScript); }); } } // 初始化 const router new MpaRouter({ /user-management: https://user-app.example.com, /order-center: https://order-app.example.com, /legacy-report: https://legacy.example.com/reports });实操心得executeScripts函数至关重要。通过fetch获取的 HTML 中的script标签在被插入 DOM 时不会自动执行。我们必须手动创建新的 script 元素来替换它们才能触发脚本执行。同时要确保src为外部资源的脚本也能正确加载这依赖于前面提到的资源路径必须正确。3.2 子应用的构建配置要点以一个使用 Webpack 的 Vue.js 子应用为例关键的配置在于publicPath和可能需要的输出格式调整。// vue-app/vue.config.js const { defineConfig } require(vue/cli-service); module.exports defineConfig({ // 关键设置正确的 publicPath // 假设子应用将独立部署在 https://assets.mycompany.com/user-app/ publicPath: process.env.NODE_ENV production ? https://assets.mycompany.com/user-app/ // CDN或独立域名 : /, // 开发环境 // 确保资源文件名包含哈希利于缓存和更新 filenameHashing: true, // 如果你希望主应用能像加载普通页面一样加载可以输出一个完整的HTML。 // 但更优的做法是提供一个“片段”入口主应用只加载这个片段。 // 这需要额外的配置例如使用一个特殊的入口文件只导出组件而非完整应用。 })更高级的做法是提供“应用片段”。我们可以构建两个入口一个用于独立运行的完整应用app.html另一个是仅包含应用根组件渲染逻辑的 JavaScript 片段fragment.js。主应用加载这个片段并执行传入容器元素。这种方式资源控制更精细但子应用改造量稍大。3.3 样式与脚本隔离的实践样式隔离对于 Vue 应用style scoped是天然的隔离方案。对于 React可以使用 CSS Modules。如果子应用使用了全局 CSS 库如 Bootstrap一个折中方案是在主应用的布局中为子应用容器包裹一个具有特定类名或 ID 的 div然后让子应用的 CSS 规则都嵌套在这个选择器下。但这需要构建工具支持 CSS 重写实现成本较高。脚本隔离确保子应用的入口文件是模块化的。对于 Webpack 打包的应用默认输出就是一个 IIFE 或模块通常不会污染全局。但要特别注意避免直接向window对象挂载大量属性。如果必须挂载如某些 SDK使用具有命名空间的名称例如window.__UserApp_SDK。在应用“卸载”时虽然对 MPA 来说是页面跳转但主应用可能会清理容器清理定时器、事件监听器、取消网络请求等。这需要子应用暴露一个清理函数并由主应用在加载新页面前调用。// 子应用入口 (fragment.js) (function() { let cleanupHandlers []; function mount(container, props) { // 渲染逻辑... const resizeHandler () console.log(resize); window.addEventListener(resize, resizeHandler); // 注册清理函数 cleanupHandlers.push(() { window.removeEventListener(resize, resizeHandler); }); } function unmount() { // 执行所有清理操作 cleanupHandlers.forEach(handler handler()); cleanupHandlers []; } // 暴露给主应用调用的接口 window.__MyMicroApp { mount, unmount }; })();在主应用加载新子应用前可以尝试调用window.__MyMicroApp?.unmount()进行清理。4. 部署与运维方案MPA 微前端的部署相对简单但也需要规划。4.1 独立部署与域名规划最理想的模式是每个子应用拥有独立的二级域名或路径并支持 HTTPS。方案A独立域名user-app.example.com,order-app.example.com。优势是隔离彻底Cookie 可以按域名隔离。缺点是可能遇到跨域问题需要配置 CORS且域名较多。方案B路径区分主应用在www.example.com子应用部署在www.example.com/user-app/,www.example.com/order-app/。通过 Nginx 等反向代理将不同路径的请求转发到不同的后端服务或静态资源服务器。这种方式避免了跨域更简洁。反向代理配置示例 (Nginx)server { listen 80; server_name www.example.com; location / { # 主应用静态资源 root /path/to/shell-app/dist; try_files $uri $uri/ /index.html; } location ^~ /user-app/ { # 代理到用户子应用的服务或静态目录 alias /path/to/user-app/dist/; try_files $uri $uri/ /index.html; # 或者反向代理到子应用服务器 # proxy_pass http://localhost:3001; } location ^~ /order-app/ { alias /path/to/order-app/dist/; try_files $uri $uri/ /index.html; } }4.2 版本更新与灰度发布由于子应用完全独立每个团队可以自行决定发布节奏。主应用通过子应用的入口 URL 来加载它。一个常见的实践是子应用的入口 HTML 文件如index.html本身是稳定的但其内部引用的 JavaScript 和 CSS 文件是带哈希值的。这样更新子应用只需部署新的静态资源并更新 HTML 中引用的资源路径即可。主应用无需任何改动。为了实现更可控的灰度可以在主应用的路由映射配置中做文章。例如根据用户 ID 或特征标志Feature Flag将部分用户的请求路由到新版本的子应用 URL如一个灰度环境的地址。5. 常见问题、排查技巧与避坑指南在实际落地过程中我遇到了不少问题这里总结出最典型的几个及其解决方案。5.1 资源加载 404 错误这是最常见的问题。症状是子应用的 JS、CSS、图片等资源无法加载。排查步骤打开浏览器开发者工具的 Network 面板查看失败资源的完整 URL。检查这个 URL 是否正确拼接。通常问题在于资源路径是相对路径被浏览器基于主应用的 URL如https://shell.com/#/app-a进行解析最终指向了错误的位置。解决方案确保子应用构建的publicPath配置正确。生产环境应设置为完整的绝对 URL 或正确的根路径。对于图片等资源在代码中引用时使用模块导入或确保路径以publicPath为基准。在主应用加载子应用 HTML 后可以写一个脚本遍历所有link[href],script[src],img[src]等标签检查并修复资源路径。但这只是补救措施根治还需在子应用构建时完成。5.2 JavaScript 执行错误或冲突问题子应用脚本未执行或变量冲突导致功能异常。排查查看 Console 面板是否有语法错误、变量未定义或执行错误。解决方案确认主应用的executeScripts逻辑正确特别是对于有src的外部脚本新创建的 script 标签要添加到document.body而非容器内并监听其onload/onerror事件。检查子应用的 JS 是否使用了严格模式‘use strict‘;并确保没有定义全局同名变量。利用浏览器开发者工具的 Sources 面板给子应用脚本添加断点逐步调试。5.3 样式污染与覆盖问题子应用的样式影响了主应用的导航栏或者多个子应用的样式相互干扰。排查使用 Elements 面板检查元素看最终生效的 CSS 规则来自哪个样式表。解决方案首选方案在子应用中强制使用 CSS 隔离技术Scoped CSS, CSS Modules。次选方案在主应用加载子应用内容前为容器添加一个唯一的>特性mattmezza/mpa(MPA模式)single-spa/qiankun(SPA模式)iframe模块联邦 (Module Federation)技术栈限制无限制任何能生成HTML页面的技术都行通常需支持生命周期钩子对老旧应用改造有成本无限制需使用 Webpack 5且应用间耦合度较高隔离性中等需注意样式/脚本污染高支持沙箱极高完全隔离低共享模块依赖版本需协调开发体验子应用独立开发、构建、部署体验好需要复杂的配置和改造对主应用依赖较强差调试困难通信复杂好但配置复杂对构建工具链要求高性能首屏性能好切换有白屏首屏框架开销大切换流畅差每个iframe都是完整上下文开销大构建时优化运行时性能好通信复杂度简单事件/全局状态复杂需通过框架提供的API复杂且受限postMessage简单模块导入适用场景页面级聚合、中后台、门户、整合遗留系统追求单页体验的复杂应用、交互密集型产品完全隔离的第三方页面如地图、支付应用间高度依赖、希望共享代码库的现代Web应用选型建议如果你的系统业务模块分明以页面跳转为主要交互且包含多个不同技术栈或历史包袱重的应用希望用最小成本实现整合和独立部署那么mattmezza/mpa的思路是一个非常务实且高效的选择。如果你追求极致的单页应用体验希望应用间切换如丝般顺滑且所有子应用都基于现代框架React/Vue/Angular开发愿意接受一定的框架复杂性和改造成本那么qiankun这类基于 SPA 的微前端框架更合适。iframe适用于需要绝对安全隔离的场景如嵌入完全不受控的第三方页面。模块联邦更适合一个技术栈统一、希望深度共享组件和逻辑的“巨应用”拆分解耦。在我经历的一个项目中我们需要将一个 AngularJS 的老旧后台、一个 jQuery 的报表系统和两个新的 React 功能模块整合进统一的管理平台。采用mattmezza/mpa的方案我们只花了不到两周就完成了架构搭建和初步集成各个团队几乎零改造成本。虽然页面切换时有短暂的加载感但业务方完全能够接受因为换来了开发部署的极大自由度和系统的可维护性。这个选择的关键在于清晰地认识到我们最需要解决的是“整合”与“自治”的矛盾而非“无缝体验”。
