微前端面试题及详细答案 88道（74-88）-- 实践场景与进阶扩展

《前后端面试题》专栏集合了前后端各个知识模块的面试题，包括html，javascript，css，vue，react，java，Openlayers，leaflet，cesium，mapboxGL，threejs，nodejs，mangoDB，SQL，Linux... 。

前后端面试题-专栏总目录

文章目录

• 一、本文面试题目录
• • • [74. 当一个大型单页应用拆分为微前端时，如何划分子应用的边界？](#74. 当一个大型单页应用拆分为微前端时，如何划分子应用的边界？)
    • [75. 微前端在移动端应用中的实践有哪些注意事项？](#75. 微前端在移动端应用中的实践有哪些注意事项？)
    • [76. 如何将一个已有的传统项目（如jQuery项目）改造为微前端的子应用？](#76. 如何将一个已有的传统项目（如jQuery项目）改造为微前端的子应用？)
    • [77. 微前端中如何实现全局的错误监控与日志收集？](#77. 微前端中如何实现全局的错误监控与日志收集？)
    • [78. 微前端项目中，如何实现全局的主题切换功能？](#78. 微前端项目中，如何实现全局的主题切换功能？)
    • [79. 微前端中如何处理全局的导航栏、侧边栏等公共组件？](#79. 微前端中如何处理全局的导航栏、侧边栏等公共组件？)
    • [80. 微前端在大型企业级应用（如管理后台）中的最佳实践有哪些？](#80. 微前端在大型企业级应用（如管理后台）中的最佳实践有哪些？)
    • [81. 微前端与微服务的关系是什么？它们有哪些异同点？](#81. 微前端与微服务的关系是什么？它们有哪些异同点？)
    • [82. 微前端是否可以结合Serverless架构使用？如何结合？](#82. 微前端是否可以结合Serverless架构使用？如何结合？)
    • [83. 微前端中如何实现离线缓存（PWA）支持？](#83. 微前端中如何实现离线缓存（PWA）支持？)
    • [84. 微前端的未来发展趋势有哪些？](#84. 微前端的未来发展趋势有哪些？)
    • [85. 如何设计一套自定义的微前端框架？需要考虑哪些核心模块？](#85. 如何设计一套自定义的微前端框架？需要考虑哪些核心模块？)
    • [86. 微前端中如何处理Web Worker的共享与通信？](#86. 微前端中如何处理Web Worker的共享与通信？)
    • [87. 微前端中如何实现国际化（i18n）方案的统一？](#87. 微前端中如何实现国际化（i18n）方案的统一？)
    • [88. 微前端中如何集成第三方SDK（如埋点、统计工具）？](#88. 微前端中如何集成第三方SDK（如埋点、统计工具）？)
• 二、88道微前端面试题目录列表

一、本文面试题目录

74. 当一个大型单页应用拆分为微前端时，如何划分子应用的边界？

划分子应用边界的核心是高内聚、低耦合，确保每个子应用具备独立的业务闭环和可维护性。常见划分依据如下：

• 业务领域划分：按业务模块（如电商的商品、订单、支付）拆分，每个子应用对应一个完整业务域。
• 团队职责划分：按开发团队负责的功能模块拆分，减少跨团队协作成本。
• 技术栈兼容性：将不同技术栈（如React、Vue）的模块拆分为独立子应用。
• 变更频率划分：将迭代频繁的模块与稳定模块拆分开，降低发布风险。

示例：电商平台拆分

- 基座应用（公共导航、用户信息）
- 子应用1：商品列表与详情（React技术栈）
- 子应用2：购物车与结算（Vue技术栈）
- 子应用3：用户中心（Angular技术栈）

注意事项：

• 避免拆分过细导致通信成本过高；
• 确保子应用间数据依赖最小化；
• 预留扩展接口，应对未来业务调整。

75. 微前端在移动端应用中的实践有哪些注意事项？

移动端微前端需兼顾性能、兼容性和用户体验，核心注意事项如下：

1. 性能优化 ：
   • 控制子应用体积，避免过度加载；
   • 优先使用预加载策略，减少用户等待。
2. 兼容性处理 ：
   • 针对低版本浏览器（如iOS 10、Android 6）优化沙箱机制；
   • 避免使用移动端支持较差的API（如Proxy）。
3. 体验一致性 ：
   • 统一导航栏、底部Tab等公共组件样式；
   • 确保子应用间跳转动画流畅。
4. 资源限制 ：
   • 移动端内存有限，需及时销毁卸载的子应用资源；
   • 控制并发请求数量，避免网络拥堵。

示例：Qiankun移动端配置

// 禁用Proxy沙箱，兼容低版本设备
import { start } from 'qiankun';
start({
  sandbox: {
    experimentalStyleIsolation: true, // 样式隔离
    useLooseSandbox: true, // 宽松模式沙箱，避免Proxy兼容性问题
  },
});

76. 如何将一个已有的传统项目（如jQuery项目）改造为微前端的子应用？

传统项目改造为子应用需解决加载方式、生命周期管理 和样式隔离问题，步骤如下：

1. 暴露生命周期钩子 ：
   • 在子应用中添加bootstrap、mount、unmount方法，控制初始化、渲染和销毁逻辑。
2. 处理资源路径 ：
   • 配置publicPath为相对路径或基座应用的子应用资源路径。
3. 样式隔离 ：
   • 为子应用样式添加唯一前缀（如legacy-app-），或使用框架的样式隔离机制。
4. 路由适配 ：
   • 若项目使用路由，需与基座路由协调（如基于hash路由避免冲突）。

示例：jQuery项目改造为Qiankun子应用

// 子应用入口文件（entry.js）
(function() {
  // 暴露生命周期
  window['legacy-app'] = {
    bootstrap: () => {
      console.log('jQuery应用初始化');
      return Promise.resolve();
    },
    mount: (props) => {
      // 渲染到基座提供的容器
      const container = props.container;
      $(container).html('<div class="legacy-app-content">jQuery内容</div>');
      return Promise.resolve();
    },
    unmount: (props) => {
      // 清理DOM和事件
      $(props.container).empty();
      return Promise.resolve();
    },
  };
})();

基座注册子应用：

import { registerMicroApps } from 'qiankun';
registerMicroApps([
  {
    name: 'legacy-app',
    entry: '//localhost:3001', // 子应用地址
    container: '#container',
    activeRule: '/legacy',
  },
]);

77. 微前端中如何实现全局的错误监控与日志收集？

全局错误监控需覆盖基座应用、子应用 及通信过程，实现方式如下：

1. 统一错误捕获 ：
   • 在基座应用中监听window.onerror和window.unhandledrejection；
   • 子应用内的错误通过通信机制上报至基座。
2. 框架集成 ：
   • 基于Qiankun时，可通过errorCapture钩子捕获子应用加载错误；
   • 子应用内部框架（如React的ErrorBoundary）捕获组件错误。
3. 日志收集 ：
   • 统一日志格式（包含应用名称、错误类型、堆栈信息）；
   • 定期将日志发送至后端服务。

示例：全局错误监控实现

// 基座应用中注册错误监控
function initErrorMonitor() {
  // 捕获全局同步错误
  window.onerror = (message, source, lineno, colno, error) => {
    logError({
      app: '基座应用',
      message: error?.message || message,
      stack: error?.stack,
    });
  };

  // 捕获未处理的Promise错误
  window.addEventListener('unhandledrejection', (event) => {
    logError({
      app: '基座应用',
      message: event.reason?.message || '未处理的Promise错误',
      stack: event.reason?.stack,
    });
  });
}

// 子应用错误通过通信上报
// 子应用中
props.onError((error) => {
  props.emit('error', {
    app: 'sub-app-1',
    ...error,
  });
});

// 基座中监听子应用错误
registerMicroApps([
  {
    name: 'sub-app-1',
    // ...其他配置
    props: {
      onError: (error) => logError(error),
    },
  },
]);

78. 微前端项目中，如何实现全局的主题切换功能？

全局主题切换需保证基座与子应用样式同步，实现方案如下：

1. CSS变量（推荐） ：
   • 定义全局CSS变量（如--primary-color），子应用使用变量编写样式；
   • 主题切换时，基座修改根元素的CSS变量值，子应用自动生效。
2. 主题类名切换 ：
   • 为不同主题定义独立类名（如theme-light、theme-dark）；
   • 切换时，基座修改html或body的类名，子应用样式通过类名前缀适配。
3. 动态加载样式文件 ：
   • 不同主题对应独立CSS文件，切换时动态加载并替换现有样式。

示例：基于CSS变量的主题切换

/* 基座和子应用共用的变量定义 */
:root {
  --primary-color: #1890ff;
  --text-color: #333;
}

/* 子应用样式中使用变量 */
.sub-app-button {
  background: var(--primary-color);
  color: var(--text-color);
}

// 主题切换逻辑（基座中）
function switchTheme(theme) {
  const root = document.documentElement;
  if (theme === 'dark') {
    root.style.setProperty('--primary-color', '#0f172a');
    root.style.setProperty('--text-color', '#fff');
  } else {
    root.style.setProperty('--primary-color', '#1890ff');
    root.style.setProperty('--text-color', '#333');
  }
}

79. 微前端中如何处理全局的导航栏、侧边栏等公共组件？

公共组件需保证一致性和复用性，处理方式如下：

1. 基座应用提供 ：
   • 将导航栏、侧边栏等放在基座应用中，子应用仅渲染内容区域；
   • 子应用通过通信机制控制公共组件（如动态修改导航标题）。
2. 独立公共组件库 ：
   • 将公共组件封装为独立库（如common-components），基座和子应用共同依赖；
   • 通过依赖共享机制避免重复加载。
3. 子应用适配 ：
   • 若子应用需自定义公共组件，需遵循统一的样式规范和API；
   • 通过样式隔离避免冲突（如Qiankun的experimentalStyleIsolation）。

示例：基座提供导航栏，子应用动态修改标题

// 基座应用中定义导航栏
function renderNavbar() {
  const navbar = document.getElementById('navbar');
  navbar.innerHTML = `
    <h1 id="page-title">默认标题</h1>
  `;
}

// 子应用通过props修改标题
// 子应用mount时
mount: (props) => {
  props.setPageTitle('子应用页面'); // 调用基座提供的方法
};

// 基座注册时传递方法
registerMicroApps([
  {
    name: 'sub-app',
    // ...
    props: {
      setPageTitle: (title) => {
        document.getElementById('page-title').textContent = title;
      },
    },
  },
]);

80. 微前端在大型企业级应用（如管理后台）中的最佳实践有哪些？

企业级应用微前端实践需关注可维护性、扩展性和安全性，最佳实践如下：

1. 规范化子应用开发 ：
   • 制定子应用接入规范（如生命周期、通信协议、样式前缀）；
   • 使用CLI工具（如create-micro-app）快速生成符合规范的子应用。
2. 权限统一管理 ：
   • 基座应用集中处理身份认证和权限校验；
   • 子应用根据基座传递的权限信息渲染功能。
3. 灰度发布与版本控制 ：
   • 通过配置中心动态切换子应用版本；
   • 结合CI/CD实现子应用独立发布。
4. 性能监控与优化 ：
   • 集成APM工具（如Datadog、New Relic）监控各子应用性能；
   • 针对核心路径（如登录、首页加载）进行专项优化。
5. 跨应用调试 ：
   • 开发环境提供子应用列表和快速切换功能；
   • 使用qiankun-devtools等工具调试应用间通信和生命周期。

示例：企业级应用权限控制

// 基座应用权限拦截
function checkPermission(appName, path) {
  const userPermissions = JSON.parse(localStorage.getItem('permissions'));
  return userPermissions[appName]?.includes(path);
}

// 注册子应用时添加权限校验
registerMicroApps([
  {
    name: 'dashboard',
    entry: '//app.dashboard.com',
    container: '#container',
    activeRule: '/dashboard',
    beforeLoad: (app) => {
      if (!checkPermission(app.name, app.activeRule)) {
        // 无权限时跳转到403页面
        router.push('/403');
        return Promise.reject(new Error('无权限访问'));
      }
      return Promise.resolve();
    },
  },
]);

81. 微前端与微服务的关系是什么？它们有哪些异同点？

微前端与微服务均基于拆分思想提升系统可维护性，但面向层次不同：

维度	微前端	微服务
面向对象	前端应用（浏览器端）	后端服务（服务器端）
拆分单位	按业务模块拆分前端应用	按业务领域拆分后端服务
核心目标	解决前端技术栈异构、独立部署问题	解决后端服务耦合、扩展性问题
通信方式	基于浏览器内存（如Pub/Sub）	基于网络协议（如HTTP、gRPC）
部署方式	静态资源部署（CDN、对象存储）	容器化部署（Docker、K8s）

关系：

• 微前端与微服务可协同工作：前端按微前端拆分，对应后端微服务接口；
• 微前端不依赖微服务，但微服务架构常搭配微前端提升整体系统灵活性。

82. 微前端是否可以结合Serverless架构使用？如何结合？

微前端与Serverless可协同工作，Serverless提供后端支持，微前端负责前端聚合，结合方式如下：

1. 子应用独立部署至Serverless静态托管 ：
   • 将子应用静态资源部署到Serverless静态托管服务（如AWS S3、阿里云OSS）；
   • 通过CDN加速资源访问，降低 latency。
2. 动态配置中心 ：
   • 使用Serverless函数（如AWS Lambda、阿里云FC）作为配置中心；
   • 基座应用从函数获取子应用列表和版本信息，实现动态注册。
3. 按需加载后端能力 ：
   • 子应用的后端接口通过Serverless函数实现，按需调用（如用户中心子应用调用用户相关函数）；
   • 避免传统后端服务的资源浪费。

示例：基于Serverless的子应用动态注册

// 基座应用从Serverless函数获取子应用配置
async function fetchMicroApps() {
  const response = await fetch('https://api.example.com/get-micro-apps'); // 调用Serverless函数
  const apps = await response.json();
  return apps;
}

// 动态注册子应用
fetchMicroApps().then((apps) => {
  registerMicroApps(apps.map(app => ({
    name: app.name,
    entry: app.entry,
    container: '#container',
    activeRule: app.activeRule,
  })));
  start();
});

83. 微前端中如何实现离线缓存（PWA）支持？

微前端结合PWA需解决子应用资源缓存 和缓存一致性问题，实现方案如下：

1. 基座应用集成Service Worker ：
   • 基座的Service Worker负责缓存公共资源（如基座本身、共享库）；
   • 拦截子应用资源请求，优先从缓存加载。
2. 子应用资源缓存策略 ：
   • 子应用注册时，基座动态将其资源URL添加到缓存列表；
   • 使用workbox等工具简化缓存管理。
3. 缓存更新机制 ：
   • 子应用版本变更时，通过Service Worker更新对应缓存；
   • 基座提供"强制刷新"功能，处理缓存不一致问题。

示例：基于Workbox的微前端缓存配置

// 基座应用的service-worker.js（使用Workbox）
import { precacheAndRoute, createHandlerBoundToURL } from 'workbox-precaching';
import { registerRoute } from 'workbox-routing';

// 预缓存基座资源
precacheAndRoute(self.__WB_MANIFEST);

// 动态缓存子应用资源
registerRoute(
  ({ url }) => url.pathname.startsWith('/sub-apps/'), // 子应用资源路径
  new workbox.strategies.StaleWhileRevalidate({
    cacheName: 'micro-apps-cache',
  })
);

子应用注册时通知Service Worker缓存：

// 基座应用中
function registerMicroAppWithCache(app) {
  // 注册子应用
  registerMicroApps([app]);
  // 通知Service Worker缓存子应用入口资源
  if ('serviceWorker' in navigator) {
    navigator.serviceWorker.controller.postMessage({
      type: 'CACHE_SUB_APP',
      url: app.entry,
    });
  }
}

84. 微前端的未来发展趋势有哪些？

微前端未来将向更轻量、更原生、更智能方向发展，主要趋势如下：

1. 浏览器原生支持增强 ：
   • 依赖Web Components、ES模块等原生特性，减少框架层抽象；
   • 浏览器可能提供更原生的应用隔离机制（如iframe增强）。
2. 构建时集成优化 ：
   • 从"运行时集成"向"构建时预集成"演进，通过模块联邦（Module Federation）等技术减少运行时开销；
   • 静态分析工具自动检测子应用冲突并优化。
3. 智能化加载与资源管理 ：
   • 基于用户行为预测预加载子应用；
   • AI驱动的性能优化（如动态调整缓存策略）。
4. 跨端统一 ：
   • 微前端思想扩展至移动端（如React Native、Flutter），实现多端应用聚合；
   • 统一的跨端通信和状态管理方案。
5. 低代码与微前端结合 ：
   • 低代码平台生成的模块作为子应用接入，提升开发效率；
   • 可视化配置子应用关系和通信规则。

85. 如何设计一套自定义的微前端框架？需要考虑哪些核心模块？

设计自定义微前端框架需覆盖应用管理、隔离、通信、路由四大核心能力，核心模块如下：

1. 应用注册与管理模块 ：
   • 提供registerApp、unregisterApp接口管理子应用；
   • 维护应用状态（加载中、已挂载、已卸载）。
2. 加载器模块 ：
   • 支持多种加载方式（如Script标签、Fetch+eval、ES模块）；
   • 处理资源路径和依赖加载。
3. 沙箱隔离模块 ：
   • 实现JS沙箱（基于Proxy或快照模式）；
   • 提供样式隔离（CSS Modules、Shadow DOM）。
4. 路由分发模块 ：
   • 监听URL变化，匹配对应的子应用；
   • 支持路由嵌套和参数传递。
5. 通信模块 ：
   • 提供Pub/Sub或API调用机制；
   • 支持跨应用数据共享。
6. 生命周期管理模块 ：
   • 定义bootstrap、mount、unmount等钩子；
   • 协调子应用激活与卸载顺序。

示例：简化版自定义框架核心代码

class MicroFrontendFramework {
  constructor() {
    this.apps = []; // 注册的应用
    this.activeApp = null; // 当前激活的应用
  }

  // 注册应用
  registerApp(appConfig) {
    this.apps.push(appConfig);
  }

  // 启动框架
  start() {
    this.setupRouter(); // 初始化路由监听
  }

  // 路由匹配与应用激活
  setupRouter() {
    window.addEventListener('hashchange', () => this.matchAndActivate());
    this.matchAndActivate(); // 初始匹配
  }

  async matchAndActivate() {
    const currentPath = window.location.hash;
    const matchedApp = this.apps.find(app => currentPath.startsWith(app.activeRule));
    if (!matchedApp) return;

    // 卸载当前应用
    if (this.activeApp && this.activeApp.name !== matchedApp.name) {
      await this.activeApp.instance.unmount();
    }

    // 加载并激活新应用
    if (!matchedApp.instance) {
      matchedApp.instance = await this.loadApp(matchedApp);
      await matchedApp.instance.bootstrap();
    }
    await matchedApp.instance.mount({ container: '#app-container' });
    this.activeApp = matchedApp;
  }

  // 加载应用（简化版）
  async loadApp(app) {
    const script = document.createElement('script');
    script.src = app.entry;
    document.head.appendChild(script);
    return new Promise(resolve => {
      script.onload = () => {
        resolve(window[app.name]); // 假设应用暴露在window上
      };
    });
  }
}

// 使用示例
const mff = new MicroFrontendFramework();
mff.registerApp({
  name: 'app1',
  entry: '//localhost:3001/entry.js',
  activeRule: '#/app1',
});
mff.start();

86. 微前端中如何处理Web Worker的共享与通信？

Web Worker共享需解决跨应用Worker复用 和通信隔离问题，实现方案如下：

1. 基座统一管理Worker ：
   • 基座应用创建全局Worker池，子应用通过基座申请Worker；
   • 避免子应用重复创建Worker导致资源浪费。
2. 通信代理机制 ：
   • 基座为每个子应用分配独立的通信信道（如MessageChannel）；
   • 子应用通过代理与Worker通信，基座负责消息转发和隔离。
3. Worker资源共享 ：
   • 将通用计算逻辑（如数据处理、加密）封装为共享Worker；
   • 子应用通过SharedWorker接口共享同一实例。

示例：基座管理的Worker池

// 基座应用中创建Worker池
class WorkerPool {
  constructor() {
    this.workers = new Map(); // key: workerName, value: Worker
  }

  getWorker(workerName) {
    if (!this.workers.has(workerName)) {
      this.workers.set(workerName, new Worker(`/workers/${workerName}.js`));
    }
    return this.workers.get(workerName);
  }

  // 为子应用创建通信代理
  createProxy(appName, workerName) {
    const worker = this.getWorker(workerName);
    const channel = new MessageChannel();

    // 子应用侧端口
    const appPort = channel.port1;
    // Worker侧端口（添加应用标识）
    const workerPort = channel.port2;
    workerPort.postMessage({ type: 'REGISTER_APP', appName });
    worker.postMessage({ type: 'BIND_PORT', port: workerPort }, [workerPort]);

    return appPort;
  }
}

// 子应用获取Worker代理
// 子应用mount时
mount: (props) => {
  const dataWorker = props.getWorkerProxy('data-processor');
  dataWorker.onmessage = (e) => {
    console.log('子应用收到Worker消息:', e.data);
  };
  dataWorker.postMessage({ type: 'PROCESS', data: [1, 2, 3] });
};

87. 微前端中如何实现国际化（i18n）方案的统一？

统一国际化需保证语言切换同步 和文案一致性，实现方案如下：

1. 基座主导语言管理 ：
   • 基座应用维护全局语言状态（如zh-CN、en-US）；
   • 子应用通过通信获取当前语言，并监听语言变化事件。
2. 共享翻译资源 ：
   • 将公共文案（如"确定"、"取消"）放在共享库中；
   • 子应用私有文案由自身管理，遵循统一格式。
3. 统一API设计 ：
   • 定义全局$t翻译函数，子应用通过基座注入；
   • 支持文案插值、复数等高级功能。

示例：基于i18next的统一国际化

// 基座应用初始化i18n
import i18n from 'i18next';
import { initReactI18next } from 'react-i18next';

i18n
  .use(initReactI18next)
  .init({
    lng: 'zh-CN',
    resources: {
      'zh-CN': { common: { confirm: '确定', cancel: '取消' } },
      'en-US': { common: { confirm: 'Confirm', cancel: 'Cancel' } },
    },
  });

// 提供给子应用的API
function getI18nAPI() {
  return {
    t: (key) => i18n.t(key),
    onLanguageChange: (callback) => i18n.on('languageChanged', callback),
    changeLanguage: (lng) => i18n.changeLanguage(lng),
  };
}

// 注册子应用时注入i18n
registerMicroApps([
  {
    name: 'sub-app',
    // ...
    props: {
      i18n: getI18nAPI(),
    },
  },
]);

子应用使用：

// 子应用中
mount: (props) => {
  const { t, onLanguageChange } = props.i18n;
  console.log(t('common.confirm')); // 输出当前语言的"确定"

  // 监听语言变化
  onLanguageChange((lng) => {
    console.log('语言切换为:', lng);
    // 子应用重新渲染
  });
};

88. 微前端中如何集成第三方SDK（如埋点、统计工具）？

集成第三方SDK需平衡统一性 和子应用独立性，实现方案如下：

1. 基座统一集成 ：
   • 全局SDK（如百度统计、友盟）由基座加载，子应用通过基座提供的API调用；
   • 避免子应用重复加载SDK导致冲突。
2. 子应用按需集成 ：
   • 子应用特有SDK（如支付SDK）由子应用自行加载；
   • 通过沙箱隔离避免对其他应用的影响。
3. 统一埋点规范 ：
   • 基座定义埋点格式（如包含应用名称、页面路径）；
   • 子应用按规范调用埋点方法，确保数据可聚合分析。

示例：基座集成埋点SDK并提供API

// 基座应用集成埋点SDK
import '@baidu-tongji/analytics'; // 假设的百度统计SDK

// 封装埋点方法
const tracker = {
  trackPageView: (appName, page) => {
    _hmt.push(['_trackPageview', `/${appName}/${page}`]);
  },
  trackEvent: (appName, category, action) => {
    _hmt.push(['_trackEvent', appName, category, action]);
  },
};

// 注入到子应用
registerMicroApps([
  {
    name: 'sub-app',
    // ...
    props: {
      tracker: {
        trackPageView: (page) => tracker.trackPageView('sub-app', page),
        trackEvent: (category, action) => tracker.trackEvent('sub-app', category, action),
      },
    },
  },
]);

子应用使用：

// 子应用mount时上报页面
mount: (props) => {
  props.tracker.trackPageView('/home');
  // 按钮点击事件上报
  document.getElementById('btn').addEventListener('click', () => {
    props.tracker.trackEvent('button', 'click');
  });
};

二、88道微前端面试题目录列表

文章序号	微前端面试题88道
1	微前端面试题及详细答案88道（01-08）
2	微前端面试题及详细答案88道（09-18）
3	微前端面试题及详细答案88道（19-35）
4	微前端面试题及详细答案88道（36-43）
5	微前端面试题及详细答案88道（44-60）
6	微前端面试题及详细答案88道（61-73）
7	微前端面试题及详细答案88道（74-88）