微前端对比 & 各方案实现原理
笔试题（6 题）
1. 微前端核心问题
微前端要解决什么问题？它引入了哪些新的复杂度？适用和不适用的场景分别是什么？
【作答】：
要解决的问题：
1. 团队协作问题：
- 多团队并行开发，避免代码冲突
- 不同团队技术栈独立（React、Vue、Angular 可共存）
- 降低团队间的沟通成本和依赖
2. 代码膨胀问题：
- 单体应用代码量过大（10万+行代码）
- 构建时间长（5-10分钟）
- 开发体验差（热更新慢）
3. 发布部署问题：
- 单体应用牵一发动全身，任何改动都需要全量发布
- 发布风险高，回滚代价大
- 无法做到按模块独立部署
4. 业务隔离问题：
- 核心业务与边缘业务耦合
- 不同业务线需要独立迭代
- 历史代码重构成本高
5. 技术债务问题：
- 老代码技术栈无法升级（如 React 15 → React 18）
- 新老代码共存，逐步迁移
引入的新复杂度：
1. 技术复杂度：
- JS 隔离（沙箱机制）
- CSS 隔离（样式冲突）
- 路由劫持与同步
- 应用间通信机制
- 公共依赖管理与版本冲突
2. 工程复杂度：
- 构建配置复杂（主应用 + 多个子应用）
- 联调困难（本地开发需要启动多个应用）
- 部署流程复杂（独立部署 + 资源加载）
- 版本管理复杂（多仓库/Monorepo）
3. 运维复杂度：
- 资源加载性能（多个应用的 JS/CSS 加载）
- 错误边界与降级（某个子应用挂了不能影响主应用）
- 监控与日志（需要区分不同应用的错误）
- 灰度发布与回滚（多应用协同）
4. 开发体验复杂度：
- 调试困难（跨应用调试）
- 本地开发环境搭建复杂
- 需要学习微前端框架（qiankun、Module Federation）
适用场景：
✅ 大型中后台系统：
- 多个业务模块（订单、库存、财务、CRM 等）
- 多团队协作（5+ 团队）
- 代码量大（10万+ 行）
- 示例：企业 ERP、电商后台、政务系统
✅ 跨技术栈整合：
- 历史系统是 Vue，新系统用 React
- 逐步迁移技术栈，新老系统共存
- 收购的第三方系统需要整合
✅ 独立业务模块：
- 业务模块相对独立（低耦合）
- 各模块独立部署需求强烈
- 不同模块由不同供应商开发
✅ 多租户 SaaS 平台：
- 不同租户可能需要不同的定制模块
- 插件化需求（可动态加载/卸载模块）
不适用场景：
❌ 小型项目：
- 代码量 < 5万行
- 团队 < 5 人
- 引入微前端收益 < 成本
❌ 高性能要求场景：
- C端应用对首屏性能要求极高（如电商首页）
- 微前端额外的 JS 加载会影响性能
- 应优先考虑代码分割、懒加载
❌ 强交互应用：
- 子应用间需要频繁通信（如实时协作工具）
- 组件级复用需求强（应考虑组件库，而非微前端）
- 状态共享复杂（Redux/MobX 全局状态）
❌ 移动端 H5：
- 移动端性能敏感
- 额外的框架代码和沙箱机制会影响性能
- 应优先考虑 PWA、离线化
❌ 技术栈统一的团队：
- 团队已经统一技术栈（如全部 React）
- 使用 Monorepo + 模块化即可解决问题
- 不需要微前端的隔离能力
决策原则：
- 收益 > 成本：解决的问题价值 > 引入的复杂度
- 团队规模：5+ 团队才考虑
- 代码规模：10万+ 行代码才考虑
- 独立部署：如果不需要独立部署，不要用微前端2. 微前端方案对比
主流方案对比：iframe / single-spa / qiankun / Module Federation 的核心差异，优缺点对比表。
【作答】：
iframe:
优点：
✅ 天然隔离（JS、CSS、DOM 完全隔离）
✅ 实现简单，零技术门槛
✅ 浏览器原生支持，稳定性好
✅ 可以加载任意第三方页面
缺点：
❌ 性能差（每个 iframe 是独立的浏览器上下文）
❌ 路由同步困难（iframe 内部路由无法同步到主应用 URL）
❌ 弹窗/遮罩层体验差（受 iframe 边界限制）
❌ 白屏时间长（独立加载所有资源）
❌ 内存占用高（多个完整的浏览器上下文）
❌ 通信复杂（postMessage，不同域需要 CORS）
❌ SEO 不友好
适用场景：
- 嵌入第三方页面（如支付页面、BI 报表）
- 对性能要求不高的后台管理系统
- 需要强隔离的场景（安全性要求高）
---
single-spa:
优点：
k/
- 各应用独立的组件
- 原因：独立迭代、避免耦合
2. 治理策略：
策略1：Monorepo 统一管理
- 所有应用在一个仓库
- package.json 统一版本
- 好处：版本强制统一
project/
├── packages/
│ ├── main-app/ (主应用)
│ ├── sub-app-1/ (子应用1)
│ └── sub-app-2/ (子应用2)
└── package.json (统一依赖版本)
策略2：依赖版本清单
- 维护一份依赖版本清单（versions.json）
- 所有应用遵循清单版本
// versions.json
{
"react": "18.2.0",
"react-dom": "18.2.0",
"antd": "5.0.0"
}
策略3：CI 检查
- 在 CI 阶段检查依赖版本
- 不符合规范则阻止部署
// 检查脚本
const checkVersions = () => {
const pkg = require('./package.json')
if (pkg.dependencies.react !== '18.2.0') {
throw new Error('React 版本不符合规范')
}
}
策略4：公共依赖中心化
- 主应用统一管理公共依赖
- 子应用通过主应用获取
// 主应用暴露依赖
window.__SHARED_LIBS__ = {
react: React,
reactDOM: ReactDOM,
antd: antd
}
// 子应用使用
const React = window.__SHARED_LIBS__.react
3. 依赖升级流程：
步骤1：评估影响范围
- 哪些应用使用了该依赖
- 升级是否有 Breaking Changes
步骤2：统一升级
- 所有应用同步升级
- 避免版本碎片化
步骤3：测试验证
- 主应用测试
- 所有子应用测试
步骤4：灰度发布
- 先发布一个子应用
- 验证无问题后全量发布
---
external（外部化）：
定义：
- 将依赖标记为外部依赖
- 不打包到 bundle 中
- 运行时从外部获取（如 CDN、window 全局变量）
配置方式：
// webpack.config.js
module.exports = {
externals: {
react: 'React', // window.React
'react-dom': 'ReactDOM', // window.ReactDOM
jquery: 'jQuery' // window.jQuery
}
}
使用场景：
1. CDN 加载：
- 通过 CDN 加载 React
- 所有应用共享同一个 CDN 资源
{/* index.html */}
<script src="https://cdn.jsdelivr.net/npm/react@18/umd/react.production.min.js"></script>
<script src="https://cdn.jsdelivr.net/npm/react-dom@18/umd/react-dom.production.min.js"></script>
2. 主应用提供：
- 主应用加载依赖到 window
- 子应用通过 external 使用
// 主应用
import React from 'react'
window.React = React
// 子应用 webpack 配置
externals: {
react: 'React'
}
优点：
✅ 减少子应用体积
✅ 利用浏览器缓存（CDN）
✅ 强制版本统一（都用同一个 window.React）
缺点：
❌ 需要手动管理加载顺序
❌ CDN 不稳定可能影响可用性
❌ 调试困难（CDN 压缩代码）
❌ 无法按需加载（必须全量加载）
最佳实践：
- 适合稳定的大型依赖（React、Vue）
- 生产环境使用，开发环境关闭（便于调试）
- 配合 CDN fallback（CDN 失败时本地加载）
---
shared（共享依赖，Module Federation）：
定义：
- Webpack 5 Module Federation 的共享机制
- 运行时动态协商依赖版本
- 自动去重，按需加载
配置方式：
new ModuleFederationPlugin({
shared: {
// 简单配置
react: '^18.0.0',
// 详细配置
'react-dom': {
singleton: true, // 单例模式
requiredVersion: '^18.0.0', // 版本要求
eager: false, // 是否立即加载
strictVersion: false // 严格版本检查
}
}
})
工作机制：
1. 编译时：
- 分析依赖，生成共享清单
- 记录版本信息
2. 运行时：
- 主应用和子应用协商版本
- 选择合适的版本（通常是最高兼容版本）
- 共享同一个实例
优点：
✅ 自动版本协商（无需手动管理）
✅ 按需加载（懒加载，减少首屏时间）
✅ 灵活性高（可配置降级策略）
✅ 支持多版本共存（兼容性好）
缺点：
❌ 配置复杂（需要理解 singleton、eager 等概念）
❌ 调试困难（运行时动态加载）
❌ 版本冲突时可能加载多份（体积增加）
适用场景：
- 使用 Webpack 5 + Module Federation
- 依赖版本可能不完全一致
- 需要灵活的版本管理
对比 external：
| 特性 | external | shared |
|-----------|----------------|---------------------|
| 加载时机 | 编译时决定 | 运行时协商 |
| 版本管理 | 手动 | 自动 |
| 灵活性 | 低 | 高 |
| 体积优化 | 好 | 中等 |
| 适用场景 | 稳定依赖 | 动态依赖 |
---
singleton（单例模式）：
定义：
- 保证全局只有一个依赖实例
- 所有应用共享同一个实例
- 版本冲突时强制使用一个版本
配置方式：
shared: {
react: {
singleton: true // 开启单例
}
}
工作机制：
1. 首次加载：
- 主应用加载 React 18.2.0
- 注册到全局共享作用域
2. 子应用请求：
- 子应用需要 React 18.1.0
- 检测到已有 React 18.2.0
- 复用 18.2.0（而非加载新版本）
3. 版本冲突：
- 如果子应用需要 React 17.0.0（不兼容）
- strictVersion: false → 告警，但仍使用 18.2.0
- strictVersion: true → 直接报错
为什么需要 singleton：
1. React 的要求：
- React 不支持多实例（Hooks 依赖单例）
- 多个 React 实例会导致 Hooks 报错
错误示例：
Error: Invalid hook call. Hooks can only be called inside of the body of a function component.
2. 状态管理：
- Redux、MobX 等状态管理库需要单例
- 多实例会导致状态不同步
3. 性能考虑：
- 减少重复加载
- 降低内存占用
适用依赖：
✅ 必须 singleton：
- React / React-DOM
- Vue
- Redux / MobX
- React-Router
⚠️ 可选 singleton：
- Ant Design（建议单例，但多实例也能用）
- lodash（多实例无影响，但浪费资源）
❌ 不需要 singleton：
- 纯工具函数
- 业务组件
配置示例：
shared: {
// 必须单例
react: {
singleton: true,
strictVersion: true // 严格模式，版本不匹配报错
},
// 建议单例
antd: {
singleton: true,
strictVersion: false // 宽松模式，版本不匹配告警
},
// 可选单例
lodash: {
singleton: false // 允许多版本
}
}
---
版本冲突处理：
1. 预防策略：
策略1：版本锁定（package-lock.json）
- 锁定所有依赖的精确版本
- 避免安装时版本变化
策略2：版本规范
- 制定版本规范文档
- 统一主要依赖的版本（React、Ant Design）
策略3：依赖检查工具
- 开发工具检查依赖版本
- CI 阶段强制检查
// check-deps.js
const checkDeps = () => {
const mainPkg = require('../main-app/package.json')
const subPkg = require('../sub-app/package.json')
if (mainPkg.dependencies.react !== subPkg.dependencies.react) {
throw new Error('React 版本不一致')
}
}
2. 运行时处理：
方案1：宽松模式（默认）
shared: {
react: {
singleton: true,
strictVersion: false, // 不严格检查
requiredVersion: '^18.0.0'
}
}
- 版本不匹配时告警，但继续运行
- 风险：可能运行时错误
方案2：严格模式
shared: {
react: {
singleton: true,
strictVersion: true // 严格检查
}
}
- 版本不匹配直接报错
- 强制修复版本问题
方案3：降级加载
shared: {
react: {
singleton: false // 允许多版本
}
}
- 各应用加载各自版本
- 缺点：体积增加、多实例问题
3. 监控与告警：
// 版本冲突监控
const monitorSharedDeps = () => {
const sharedScope = window.__webpack_share_scopes__.default
Object.keys(sharedScope).forEach(dep => {
const versions = Object.keys(sharedScope[dep])
if (versions.length > 1) {
console.warn(`${dep} 存在多个版本:`, versions)
// 上报监控系统
reportVersionConflict(dep, versions)
}
})
}
4. 实际案例与解决方案：
案例1：React 版本冲突
问题：主应用 React 18，子应用 React 17
方案：升级子应用
✅ 推荐：升级子应用到 React 18
⚠️ 临时：singleton: false，加载两份（可能 Hooks 报错）
案例2：Ant Design 版本冲突
问题：不同子应用使用 Ant Design 4 和 5
方案1：统一升级到 Ant Design 5
方案2：各自加载（不共享 antd）
shared: {
// antd 不共享，各自打包
}
案例3：工具库版本冲突
问题：lodash 4.17.20 和 4.17.21
方案：允许多版本（影响小）
shared: {
lodash: {
singleton: false
}
}
5. 最佳实践总结：
✅ 核心依赖必须统一版本（React、Vue）
✅ 使用 Monorepo 或版本清单管理
✅ CI 阶段检查依赖版本
✅ 建立版本升级机制（定期统一升级）
✅ 监控运行时版本冲突
❌ 避免过度使用 strictVersion（容易报错）
❌ 避免版本碎片化（每个应用版本都不同）
❌ 避免手动修改 package-lock.json面试题（4 题）
1. 微前端适用性判断
你的业务适不适合微前端？给出判断标准、评估维度与反例（什么情况下不应该用）。
【作答】：
判断标准（评分表）：
维度1：团队规模（权重 30%）
├─ 5+ 个独立团队：+30分 ✅ 强烈推荐
├─ 3-4 个团队：+20分 ⚠️ 可以考虑
├─ 1-2 个团队：+5分 ❌ 不推荐
└─ 理由：微前端主要解决多团队协作问题
维度2：代码规模（权重 25%）
├─ 10万+ 行代码：+25分 ✅ 强烈推荐
├─ 5-10万 行代码：+15分 ⚠️ 可以考虑
├─ < 5万 行代码：+5分 ❌ 不推荐
└─ 理由：代码量大才有拆分价值
维度3：独立部署需求（权重 25%）
├─ 必须独立部署：+25分 ✅ 强烈推荐
├─ 偶尔独立部署：+15分 ⚠️ 可以考虑
├─ 不需要独立部署：+0分 ❌ 不推荐
└─ 理由：独立部署是微前端的核心价值
维度4：技术栈差异（权重 15%）
├─ 多技术栈（React+Vue）：+15分 ✅ 推荐
├─ 单技术栈，但需要渐进式迁移：+10分 ⚠️ 可以考虑
├─ 单技术栈统一：+0分 ⚠️ 收益不明显
└─ 理由：技术栈统一可用 Monorepo
维度5：业务耦合度（权重 5%）
├─ 业务模块独立（低耦合）：+5分 ✅ 推荐
├─ 业务有一定依赖：+3分 ⚠️ 可以考虑
├─ 业务高度耦合：-10分 ❌ 不推荐
└─ 理由：高耦合会导致频繁跨应用通信
评分规则：
- 80-100分：✅ 强烈推荐微前端
- 60-79分：⚠️ 可以考虑，需评估收益成本
- < 60分：❌ 不推荐，收益 < 成本
---
评估维度（详细）：
1. 团队维度：
✅ 适合：
- 多团队并行开发（5+ 团队）
- 团队地域分散（不同城市）
- 团队技术栈不同
- 团队独立性强（各自负责一块业务）
❌ 不适合：
- 单一小团队（< 5人）
- 团队紧密协作（频繁跨团队开发）
- 团队技术能力弱（学习成本高）
2. 业务维度：
✅ 适合：
- 多个独立业务模块（订单、库存、财务）
- 业务模块相对独立（低耦合）
- 不同业务迭代节奏不同
- 中后台系统（ToB）
❌ 不适合：
- 单一业务（如单纯的博客系统）
- 业务高度耦合（频繁跨模块调用）
- C端高性能要求（首屏性能敏感）
- 强交互应用（实时协作）
3. 技术维度：
✅ 适合：
- 历史技术栈迁移（Vue 2 → Vue 3 / React）
- 多技术栈并存需求
- 大型单体应用重构
- 需要独立升级技术栈
❌ 不适合：
- 技术栈统一且稳定
- 团队对微前端不熟悉
- 对性能要求极高（额外开销不可接受）
4. 部署维度：
✅ 适合：
- 需要独立部署（高频发布）
- 不同模块发布周期不同
- 需要灰度发布
- 回滚风险隔离
❌ 不适合：
- 统一发布即可
- 发布频率低（月度发布）
- 部署流程复杂度不可接受
5. 规模维度：
✅ 适合：
- 代码量 > 10万行
- 构建时间 > 5分钟
- 应用启动时间 > 30秒
- 团队 > 10人
❌ 不适合：
- 小型项目（< 5万行）
- 构建时间可接受（< 2分钟）
- 团队小（< 5人）
---
反例（不应该用微前端的场景）：
反例1：个人博客系统
- 代码量：5000 行
- 团队：1 人
- 业务：单一博客功能
- 结论：❌ 完全没必要，用 Next.js 单体应用即可
- 理由：引入微前端纯属过度设计
反例2：创业公司 MVP 产品
- 代码量：2 万行
- 团队：3 人
- 业务：快速迭代验证
- 结论：❌ 不适合，浪费时间
- 理由：
· 团队小，不存在协作问题
· 业务变化快，架构复杂度是负担
· 应优先验证产品，而非过度工程化
反例3：C端电商首页
- 场景：首屏性能要求极高（< 1秒）
- 用户：百万级 DAU
- 结论：❌ 不适合
- 理由：
· 微前端额外的 JS 加载影响首屏
· 应优先考虑 SSR、代码分割、CDN
· 可以用微前端做中后台管理，但不做C端
反例4：强交互应用（实时协作工具）
- 场景：在线文档编辑（类 Google Docs）
- 特点：组件间频繁通信、状态高度共享
- 结论：❌ 不适合
- 理由：
· 应用间通信成本高
· 状态同步复杂
· 应优先考虑组件化，而非应用化
反例5：技术栈统一的团队
- 团队：全部使用 React
- 规模：10 人
- 代码：8 万行
- 结论：⚠️ 不一定需要微前端
- 理由：
· 使用 Monorepo + 代码分割可能更合适
· 微前端的技术栈隔离能力用不上
· 除非有强烈的独立部署需求
反例6：移动端 H5 应用
- 场景：移动端商城
- 特点：性能敏感、流量成本高
- 结论：❌ 不适合
- 理由：
· 额外的框架代码影响性能
· 移动端网络不稳定，加载多个应用慢
· 应优先考虑 PWA、离线化
---
决策流程图：
第一步：基础判断
Q1: 团队 >= 5 人？
├─ 否 → ❌ 不建议（考虑 Monorepo）
└─ 是 → 继续
Q2: 代码 >= 10 万行？
├─ 否 → ❌ 不建议（考虑模块化）
└─ 是 → 继续
Q3: 需要独立部署？
├─ 否 → ❌ 不建议（微前端核心价值缺失）
└─ 是 → 继续
第二步：收益评估
Q4: 是否存在以下痛点（2个以上）？
□ 多团队代码冲突频繁
□ 构建时间过长（> 5分钟）
□ 技术栈迁移困难
□ 发布风险大（牵一发动全身）
□ 业务模块耦合严重
├─ 是（2+ 痛点）→ ✅ 推荐微前端
└─ 否 → ❌ 不建议
第三步：成本评估
Q5: 团队是否能承受？
□ 学习成本（qiankun / Module Federation）
□ 改造成本（子应用需要改造）
□ 维护成本（多应用联调、部署）
├─ 能承受 → ✅ 可以尝试
└─ 不能承受 → ❌ 暂缓
---
实际案例分析：
案例1：某大型电商后台（适合）
- 团队：15 人，3 个业务组
- 代码：30 万行
- 业务：订单、库存、财务、CRM
- 技术栈：React 为主，历史遗留 jQuery
- 痛点：
· 构建时间 8 分钟
· 任何改动都需要全量发布
· 新人上手困难（代码太多）
- 方案：✅ 使用 qiankun 微前端
- 效果：
· 构建时间降至 2 分钟（各子应用独立构建）
· 独立部署，发布频率从月度到周度
· 新人只需关注自己的子应用
案例2：某政务系统（适合）
- 团队：多个外包团队（技术能力参差不齐）
- 代码：50 万行+
- 业务：审批、公文、档案、统计等20+ 模块
- 技术栈：不统一（有 Vue、React、Angular）
- 方案：✅ 使用 qiankun，iframe 兜底
- 收益：
· 各团队独立开发，减少冲突
· 技术栈隔离，各团队自主选择
· 模块独立部署，降低风险
案例3：某创业公司 ToC 产品（不适合）
- 团队：5 人
- 代码：3 万行
- 业务：社交 App
- 方案：❌ 不使用微前端
- 理由：
· 团队小，不存在协作问题
· 代码量小，模块化即可
· 性能敏感，不能接受额外开销
· 应专注于产品迭代
---
决策建议：
何时应该用微前端：
✅ 大型中后台系统（ERP、CRM、政务）
✅ 多团队协作（5+ 团队）
✅ 代码量大（10万+ 行）
✅ 需要独立部署
✅ 技术栈迁移需求
✅ 收益明显 > 成本
何时不应该用微前端：
❌ 小型项目（< 5万行）
❌ 小团队（< 5人）
❌ C端高性能要求
❌ 强交互应用
❌ 不需要独立部署
❌ 技术栈统一且稳定
❌ 团队技术能力不足
中间地带（谨慎评估）：
⚠️ 中型项目（5-10 万行）
⚠️ 中型团队（5-10 人）
⚠️ 有独立部署需求，但频率不高
⚠️ 技术栈统一，但有少量历史代码
建议：先从简单的方案开始（Monorepo、代码分割），问题严重时再引入微前端。2. 微前端基础设施
微前端下如何做"统一登录态/权限/埋点/错误上报"？如何设计主子应用的通信机制？
【作答】：
一、统一登录态
问题：
- 各子应用都需要获取用户信息
- Token 需要统一管理
- 登录状态需要同步
方案设计：
1. 主应用统一管理（推荐）：
架构：
┌──────────────────────────┐
│ 主应用（Main App） │
│ ├─ 登录页面 │
│ ├─ Token 存储(LocalStorage)│
│ ├─ 用户信息缓存 │
│ └─ 登出逻辑 │
└──────────────────────────┘
↓ props传递
┌──────────────────────────┐
│ 子应用（Sub App） │
│ ├─ 接收 token │
│ ├─ 接收 user info │
│ └─ 接收 logout 方法 │
└──────────────────────────┘
实现（qiankun）：
// 主应用
import { registerMicroApps, start } from 'qiankun'
const getToken = () => localStorage.getItem('token')
const getUserInfo = () => JSON.parse(localStorage.getItem('userInfo'))
const logout = () => {
localStorage.removeItem('token')
window.location.href = '/login'
}
registerMicroApps([
{
name: 'app1',
entry: '//localhost:8081',
container: '#container',
activeRule: '/app1',
props: {
getToken,
getUserInfo,
logout,
// 或者直接传递
token: getToken(),
userInfo: getUserInfo()
}
}
])
// 子应用
export async function mount(props) {
const { getToken, getUserInfo, logout } = props
// 使用 token
axios.defaults.headers.common['Authorization'] = `Bearer ${getToken()}`
// 使用用户信息
const userInfo = getUserInfo()
store.commit('SET_USER', userInfo)
// 登出
<Button onClick={logout}>退出登录</Button>
}
2. 共享 Token 存储：
方案1：LocalStorage 命名空间
// 主应用设置
localStorage.setItem('global:token', token)
localStorage.setItem('global:userInfo', JSON.stringify(userInfo))
// 子应用读取
const token = localStorage.getItem('global:token')
方案2：Cookie（跨域需要配置）
// 主应用设置 cookie（设置 domain）
document.cookie = `token=${token}; path=/; domain=.example.com`
// 子应用自动携带（同域）
3. SSO 单点登录（企业级）：
流程：
1. 用户访问子应用
2. 子应用检测无 token，跳转 SSO 登录页
3. SSO 登录成功，颁发 token
4. 回调到子应用，携带 token
5. 子应用保存 token
优点：
- 多系统统一认证
- 安全性高
- 支持第三方应用
缺点：
- 需要独立的 SSO 服务
- 实现复杂度高
---
二、统一权限管理
问题：
- 不同用户权限不同（菜单、按钮、路由）
- 各子应用都需要权限控制
方案设计：
1. 主应用统一权限（推荐）：
// 主应用
const permissions = {
menu: ['order', 'inventory', 'finance'], // 菜单权限
button: ['order:create', 'order:delete'], // 按钮权限
api: ['/api/order/*'] // 接口权限
}
registerMicroApps([{
name: 'app1',
props: {
permissions,
hasPermission: (code) => permissions.button.includes(code)
}
}])
// 子应用使用
export function mount(props) {
const { hasPermission } = props
// 按钮权限控制
{hasPermission('order:create') && <Button>创建订单</Button>}
// 路由权限控制
<Route path="/order/create"
render={() => hasPermission('order:create')
? <CreateOrder />
: <NoPermission />
}
/>
}
2. 权限路由自动生成：
// 主应用
const routes = [
{ path: '/app1', app: 'app1', permission: 'app1:access' },
{ path: '/app2', app: 'app2', permission: 'app2:access' }
]
const accessibleRoutes = routes.filter(route =>
hasPermission(route.permission)
)
// 根据权限动态注册子应用
registerMicroApps(accessibleRoutes.map(route => ({
name: route.app,
activeRule: route.path,
})))
3. 菜单权限过滤：
// 主应用菜单配置
const menuConfig = [
{ title: '订单管理', path: '/app1', permission: 'order:view' },
{ title: '库存管理', path: '/app2', permission: 'inventory:view' },
{ title: '财务管理', path: '/app3', permission: 'finance:view' }
]
const filteredMenu = menuConfig.filter(menu =>
hasPermission(menu.permission)
)
---
三、统一埋点
问题：
- 需要收集用户行为（页面访问、按钮点击）
- 各子应用需要统一埋点标准
方案设计：
1. 主应用提供埋点SDK（推荐）：
// 主应用初始化埋点
import Track from '@company/track-sdk'
const tracker = new Track({
appId: 'main-app',
userId: getUserId()
})
// 注入到子应用
registerMicroApps([{
name: 'app1',
props: {
tracker,
track: (event, data) => tracker.track(event, data)
}
}])
// 子应用使用
export function mount(props) {
const { track } = props
// 页面访问埋点
useEffect(() => {
track('page_view', { page: '/order/list' })
}, [])
// 按钮点击埋点
<Button onClick={() => {
track('button_click', { button: 'create_order' })
createOrder()
}}>创建订单</Button>
}
2. 路由切换自动埋点：
// 主应用监听路由变化
import { addGlobalUncaughtErrorHandler } from 'qiankun'
window.addEventListener('popstate', () => {
tracker.track('route_change', {
from: prevPath,
to: location.pathname,
app: getCurrentApp()
})
})
3. 全局事件自动采集（无侵入）：
// 主应用全局监听
document.addEventListener('click', (e) => {
const target = e.target
const trackData = target.dataset.track
if (trackData) {
tracker.track('auto_click', JSON.parse(trackData))
}
}, true)
// 子应用使用 data 属性
<Button data-track='{"type":"create_order"}'>创建</Button>
4. 性能监控埋点：
// 主应用
const performance = {
appLoad: (app, time) => {
tracker.track('app_load', { app, time })
},
apiRequest: (url, time) => {
tracker.track('api_request', { url, time })
}
}
// qiankun 生命周期埋点
addGlobalUncaughtErrorHandler((event, app) => {
tracker.track('app_load_time', {
app,
time: performance.now()
})
})
---
四、统一错误上报
问题：
- 子应用错误需要捕获
- 错误需要区分来源（哪个子应用）
- 不能让子应用错误影响主应用
方案设计：
1. 全局错误捕获（主应用）：
// 主应用
import { addGlobalUncaughtErrorHandler } from 'qiankun'
// JS 错误捕获
window.addEventListener('error', (event) => {
const currentApp = getCurrentApp()
reportError({
type: 'js_error',
app: currentApp,
message: event.message,
stack: event.error?.stack,
url: location.href
})
})
// Promise 错误捕获
window.addEventListener('unhandledrejection', (event) => {
reportError({
type: 'promise_error',
app: getCurrentApp(),
reason: event.reason
})
})
// qiankun 应用加载错误
addGlobalUncaughtErrorHandler((event, app) => {
reportError({
type: 'app_load_error',
app: app.name,
error: event
})
})
2. 子应用错误边界：
// React 子应用
class ErrorBoundary extends React.Component {
componentDidCatch(error, errorInfo) {
// 通过 props 上报错误
this.props.reportError({
type: 'react_error',
error: error.toString(),
componentStack: errorInfo.componentStack
})
}
render() {
if (this.state.hasError) {
return <h1>子应用出错了</h1>
}
return this.props.children
}
}
// mount 时包裹
export function mount(props) {
const { reportError } = props
ReactDOM.render(
<ErrorBoundary reportError={reportError}>
<App />
</ErrorBoundary>,
container
)
}
3. 错误隔离与降级：
// 主应用
registerMicroApps([{
name: 'app1',
entry: '//localhost:8081',
loader: (loading) => {
if (loading) {
showLoading()
} else {
hideLoading()
}
}
}], {
// 错误处理
errorBoundary: (error, app) => {
// 显示降级UI
showErrorPage(app.name, error)
// 上报错误
reportError({ app: app.name, error })
// 阻止错误冒泡，保护主应用
return true
}
})
4. 错误上报服务：
// 错误上报 SDK
class ErrorReporter {
report(error) {
const errorData = {
...error,
timestamp: Date.now(),
userAgent: navigator.userAgent,
url: location.href,
userId: getUserId(),
// 区分应用来源
source: error.app || 'main-app'
}
// 上报到监控平台（Sentry、阿里云 ARMS）
fetch('/api/error-report', {
method: 'POST',
body: JSON.stringify(errorData)
})
}
}
---
五、主子应用通信机制设计
问题：
- 主应用需要通知子应用（如登出、权限变更）
- 子应用需要通知主应用（如标题变更、badge 更新）
- 子应用间需要通信（如数据共享）
方案对比：
1. Props 传递（单向，简单场景）：
适用：主→子单向传递
// 主应用
registerMicroApps([{
name: 'app1',
props: {
data: { user: {} },
onEvent: (type, data) => { /* 主应用处理子应用事件 */ }
}
}])
// 子应用
export function mount(props) {
const { data, onEvent } = props
// 使用数据
console.log(props.data.user)
// 通知主应用
onEvent('badge-update', { count: 5 })
}
优点：简单直接
缺点：只能主→子，子应用无法主动获取最新数据
2. Actions 通信（qiankun 推荐）：
适用：主↔子双向通信，状态共享
// 主应用
import { initGlobalState } from 'qiankun'
const actions = initGlobalState({
user: { name: '张三' },
token: 'xxx',
theme: 'dark'
})
// 监听变化
actions.onGlobalStateChange((state, prev) => {
console.log('状态变化', state, prev)
})
// 修改状态
actions.setGlobalState({ user: { name: '李四' } })
// 传递给子应用
registerMicroApps([{
name: 'app1',
props: { actions }
}])
// 子应用
let globalActions
export function mount(props) {
globalActions = props.actions
// 监听变化
globalActions.onGlobalStateChange((state, prev) => {
// 更新本地状态
store.commit('SET_USER', state.user)
})
// 修改全局状态
globalActions.setGlobalState({ theme: 'light' })
}
优点：双向通信，状态同步
缺点：耦合度较高
3. EventBus（自定义事件）：
适用：松耦合通信，跨应用事件
// 事件总线（主应用创建）
class EventBus {
constructor() {
this.events = {}
}
on(event, callback) {
if (!this.events[event]) {
this.events[event] = []
}
this.events[event].push(callback)
}
emit(event, data) {
if (this.events[event]) {
this.events[event].forEach(cb => cb(data))
}
}
off(event, callback) {
if (this.events[event]) {
this.events[event] = this.events[event].filter(cb => cb !== callback)
}
}
}
const eventBus = new EventBus()
// 主应用
eventBus.on('logout', () => {
// 处理登出
})
registerMicroApps([{
props: { eventBus }
}])
// 子应用1发布
export function mount(props) {
const { eventBus } = props
eventBus.emit('logout')
}
// 子应用2订阅
export function mount(props) {
const { eventBus } = props
eventBus.on('logout', () => {
// 响应登出
})
}
优点：松耦合，灵活
缺点：难以追踪，调试困难
4. SharedWorker（跨标签页通信）：
适用：多标签页数据同步
const worker = new SharedWorker('/shared-worker.js')
// 发送消息
worker.port.postMessage({ type: 'update', data: {} })
// 接收消息
worker.port.onmessage = (e) => {
console.log(e.data)
}
5. LocalStorage + 监听（简单场景）：
// 主应用
localStorage.setItem('global_message', JSON.stringify({ type: 'logout' }))
// 子应用监听
window.addEventListener('storage', (e) => {
if (e.key === 'global_message') {
const message = JSON.parse(e.newValue)
handleMessage(message)
}
})
---
通信机制选择建议：
| 场景 | 推荐方案 | 理由 |
|------|---------|------|
| 主→子传递初始数据 | Props | 简单直接 |
| 主↔子双向通信 | Actions | 官方推荐，状态同步 |
| 子→主事件通知 | Props回调 | 简单场景 |
| 子↔子通信 | EventBus | 解耦 |
| 跨标签页通信 | SharedWorker / BroadcastChannel | 浏览器原生能力 |
| 复杂状态管理 | Redux + 共享store | 统一状态管理 |
最佳实践：
✅ 优先使用 qiankun Actions（官方方案）
✅ 状态最小化（只共享必要的状态）
✅ 单向数据流（主应用是唯一数据源）
✅ 避免频繁通信（性能开销）
✅ 清理监听器（unmount 时off）3. 微前端部署与发布
讲清楚"资源加载、预加载、灰度发布、回滚"在微前端架构里的方案设计。
【作答】：
一、资源加载方案
问题：
- 子应用资源如何加载（JS、CSS、图片）
- 资源路径如何处理（相对路径 vs 绝对路径）
- 如何避免资源404
方案设计：
1. HTML Entry（qiankun 推荐）：
原理：加载子应用的 HTML，提取其中的 JS/CSS
优点：
✅ 与子应用部署方式一致
✅ 支持相对路径自动转换
✅ 支持动态脚本、样式
// qiankun 使用
registerMicroApps([{
name: 'app1',
entry: 'http://localhost:8081', // HTML 地址
container: '#container'
}])
加载流程：
1. 主应用请求 http://localhost:8081/index.html
2. qiankun 解析 HTML，提取 \<script\>、<link>
3. 提取的资源相对路径转绝对路径
4. 按顺序加载 JS/CSS
5. 执行 JS，调用生命周期函数
2. JS Entry（传统方案）：
原理：直接加载子应用的 JS 入口文件
// single-spa 使用
registerApplication({
name: 'app1',
app: () => System.import('http://localhost:8081/main.js')
})
要求：
- 子应用必须打包为 UMD 格式
- 需要手动处理 CSS 加载
- 需要配置 publicPath（资源路径）
// webpack.config.js（子应用）
output: {
library: 'app1',
libraryTarget: 'umd',
publicPath: 'http://localhost:8081/' // 必须配置
}
3. 资源路径处理：
问题：子应用使用相对路径导致 404
// 子应用代码
<img src="./assets/logo.png" />
↓ 实际请求
http://main.com/assets/logo.png // ❌ 错误（主应用域名）
解决方案：
方案1：配置 publicPath（编译时）
// webpack.config.js
output: {
publicPath: process__.env.NODE_ENV === 'production'
? 'https://cdn.app1.com/'
: 'http://localhost:8081/'
}
方案2：动态 publicPath（运行时）
// 子应用入口文件
if (window.__POWERED_BY_QIANKUN__) {
__webpack_public_path__ = window.__INJECTED_PUBLIC_PATH_BY_QIANKUN__
}
方案3：使用绝对路径（推荐）
<img src="https://cdn.app1.com/assets/logo.png" />
4. 按需加载：
// React 懒加载
const OrderList = React.lazy(() => import('./OrderList'))
<Suspense fallback={<Loading />}>
<OrderList />
</Suspense>
注意：路由懒加载也需要配置 publicPath
---
二、预加载方案
问题：
- 首次进入子应用白屏时间长
- 用户体验差
方案设计：
1. qiankun 预加载（prefetch）：
// 启动时配置
start({
prefetch: true // 默认 true
})
策略：
- prefetch: true
→ 第一个子应用加载完成后，自动预加载其他子应用
- prefetch: 'all'
→ 主应用 mounted 后，立即预加载所有子应用
- prefetch: ['app1', 'app2']
→ 只预加载指定子应用
- prefetch: (apps) => { /* 自定义策略 */ }
→ 自定义预加载逻辑
2. 手动预加载：
import { prefetchApps } from 'qiankun'
// 鼠标悬停时预加载
<MenuItem
onMouseEnter={() => prefetchApps(['app1'])}
onClick={() => navigateTo('/app1')}
>
订单管理
</MenuItem>
// 空闲时预加载
if ('requestIdleCallback' in window) {
requestIdleCallback(() => {
prefetchApps(['app1', 'app2'])
})
}
3. 预加载优化策略：
策略1：核心应用优先
prefetchApps(['order-app'], {
fetch: (url) => fetch(url, { priority: 'high' })
})
策略2：网络状况判断
if (navigator.connection.effectiveType === '4g') {
prefetchApps(['app1', 'app2'])
} else {
// 弱网不预加载
}
策略3：分时预加载
setTimeout(() => prefetchApps(['app1']), 3000) // 3秒后
setTimeout(() => prefetchApps(['app2']), 6000) // 6秒后
4. Service Worker 缓存：
// sw.js
self.addEventListener('install', (event) => {
event.waitUntil(
caches.open('micro-app-cache').then((cache) => {
return cache.addAll([
'http://localhost:8081/main.js',
'http://localhost:8081/vendor.js'
])
})
)
})
// 拦截请求
self.addEventListener('fetch', (event) => {
event.respondWith(
caches.match(event.request).then((response) => {
return response || fetch(event.request)
})
)
})
5. HTTP/2 Server Push：
// Nginx 配置
location / {
http2_push /app1/main.js;
http2_push /app1/vendor.js;
}
---
三、灰度发布方案
问题：
- 新版本需要灰度测试
- 出问题需要快速回滚
- 不同用户看到不同版本
方案设计：
1. 基于用户的灰度（推荐）：
架构：
┌─────────────┐
│ 用户访问 │
└──────┬──────┘
↓
┌─────────────┐
│ 主应用 │
│ ├─ 灰度规则 │ ← 从配置中心获取
│ └─ 动态路由 │
└──────┬──────┘
↓
根据规则加载不同版本
↓
┌──────────────────┐
│ 10% 用户 → V2 │ 新版本
│ 90% 用户 → V1 │ 老版本
└──────────────────┘
实现：
// 主应用
const getAppEntry = (appName) => {
const userId = getUserId()
const grayConfig = await fetch('/api/gray-config').then(r => r.json())
// 判断用户是否在灰度名单
if (isInGrayList(userId, grayConfig)) {
return `https://app1-v2.example.com` // 新版本
} else {
return `https://app1-v1.example.com` // 老版本
}
}
registerMicroApps([{
name: 'app1',
entry: await getAppEntry('app1'),
container: '#container'
}])
灰度规则（配置中心）：
{
"app1": {
"version": "v2",
"grayType": "user",
"grayList": ["user_1", "user_2"], // 白名单
"grayPercent": 10 // 10% 流量
}
}
2. 基于流量百分比：
// 主应用
const getAppEntry = (appName) => {
const random = Math.random() * 100
const grayPercent = getGrayPercent(appName) // 从配置中心获取
if (random < grayPercent) {
return `https://app1-v2.example.com` // 10% 流量
} else {
return `https://app1-v1.example.com` // 90% 流量
}
}
3. 基于特征的灰度（AB测试）：
const getAppEntry = (appName) => {
const user = getUserInfo()
// 灰度规则
const rules = {
// VIP 用户优先体验新版本
vip: user.vip && random() < 0.5,
// 特定城市灰度
city: user.city === '北京',
// 特定浏览器灰度
browser: /Chrome/.test(navigator.userAgent)
}
if (Object.values(rules).some(v => v)) {
return `https://app1-v2.example.com`
}
return `https://app1-v1.example.com`
}
4. Nginx 层灰度（运维方案）：
# nginx.conf
upstream app1_v1 {
server app1-v1.example.com;
}
upstream app1_v2 {
server app1-v2.example.com;
}
# 根据 cookie 分流
map $cookie_version $app1_backend {
"v2" app1_v2;
default app1_v1;
}
location /app1/ {
proxy_pass http://$app1_backend;
}
5. CDN 灰度（阿里云 CDN）：
- 配置 CDN 灰度规则
- 根据 IP、地域、比例分流
- 无需修改代码
---
四、回滚方案
问题：
- 新版本有 Bug 需要快速回滚
- 不能影响用户体验
方案设计：
1. 配置中心秒级回滚（推荐）：
架构：
┌──────────────┐
│ 配置中心 │ ← 修改配置
│ app1: v2 → v1 │
└───────┬──────┘
↓ 实时推送（WebSocket）
┌──────────────┐
│ 主应用 │
│ ├─ 监听配置 │
│ └─ 动态切换 │
└───────┬──────┘
↓
重新加载子应用（使用 v1）
实现：
// 主应用
let currentVersion = {}
// 监听配置变化（WebSocket）
ws.on('config-change', (config) => {
const { app, version } = config
if (currentVersion[app] !== version) {
// 卸载旧版本
unmountMicroApp(app)
// 加载新版本
const entry = `https://${app}-${version}.example.com`
registerMicroApps([{
name: app,
entry,
container: '#container'
}])
// 刷新当前页面
if (isAppActive(app)) {
location.reload()
}
currentVersion[app] = version
}
})
// 配置中心（管理后台）
回滚操作：
1. 点击"回滚"按钮
2. 配置中心修改配置：app1.version = "v1"
3. WebSocket 推送到所有主应用
4. 主应用自动切换到 v1
耗时：< 5秒
2. CDN 回滚：
方案1：切换CDN源
// 修改 CDN 回源地址
app1.example.com → app1-v1.example.com
方案2：修改 DNS
app1.example.com A 记录
1.2.3.4 (v2) → 5.6.7.8 (v1)
缺点：DNS 生效时间长（TTL）
3. 版本管理策略：
策略1：保留历史版本（推荐）
├── app1-v1.0.0/
├── app1-v1.0.1/
├── app1-v1.1.0/ ← 当前版本
└── app1-v1.2.0/ ← 灰度版本
回滚：修改配置指向 v1.1.0
策略2：蓝绿部署
├── app1-blue/ ← 当前生产版本
└── app1-green/ ← 新版本
发布：切换流量 blue → green
回滚：切换流量 green → blue
策略3：金丝雀发布
10% 流量 → v2
90% 流量 → v1
如果 v2 有问题，停止灰度，100% 流量 → v1
4. 应用级回滚：
// 主应用提供降级UI
const FallbackApp = () => (
<div>
<h1>子应用加载失败</h1>
<Button onClick={() => loadBackupVersion()}>
加载备用版本
</Button>
</div>
)
registerMicroApps([{
name: 'app1',
entry: 'https://app1-v2.example.com',
loader: (loading) => {
if (error) {
// 自动降级到 v1
return loadApp('https://app1-v1.example.com')
}
}
}])
5. 监控与自动回滚：
// 监控错误率
const errorRate = getErrorRate('app1')
if (errorRate > 5%) { // 错误率超过5%
// 自动回滚
rollback('app1', 'v1')
// 告警通知
notify('app1 错误率过高，已自动回滚')
}
---
最佳实践总结：
资源加载：
✅ 使用 HTML Entry（qiankun）
✅ 配置 publicPath 避免 404
✅ 使用 CDN 加速
✅ 启用 HTTP/2
预加载：
✅ qiankun prefetch 开启
✅ 核心应用优先预加载
✅ 使用 Service Worker 缓存
✅ 弱网环境不预加载
灰度发布：
✅ 配置中心管理灰度规则
✅ 支持用户维度 + 流量百分比
✅ 小流量开始（1% → 10% → 50% → 100%）
✅ 实时监控灰度效果
回滚：
✅ 配置中心秒级回滚
✅ 保留历史版本
✅ 监控自动回滚
✅ 降级预案4. 子应用性能治理
如果子应用性能差拖垮主应用，你会怎么隔离与治理？如何监控、降级、容错？
【作答】：
一、性能隔离方案
问题：
- 子应用 JS 执行慢，阻塞主应用
- 子应用内存泄漏
- 子应用频繁触发重渲染
隔离策略：
1. 时间片隔离（防止长任务阻塞）：
// 主应用：限制子应用 JS 执行时间
const executeWithTimeLimit = (fn, timeout = 50) => {
return new Promise((resolve, reject) => {
const timer = setTimeout(() => {
reject(new Error('子应用执行超时'))
}, timeout)
try {
const result = fn()
clearTimeout(timer)
resolve(result)
} catch (e) {
clearTimeout(timer)
reject(e)
}
})
}
// 监控子应用挂载时间
const startTime = performance.now()
await mount()
const mountTime = performance.now() - startTime
if (mountTime > 3000) { // 超过3秒
reportPerformance({
app: 'app1',
type: 'slow_mount',
time: mountTime
})
}
2. CPU 隔离（Web Worker）：
// 将子应用耗时计算放到 Worker
// main.js
const worker = new Worker('heavy-compute.worker.js')
worker.postMessage({ data: largeData })
worker.onmessage = (e) => {
console.log('计算结果:', e.data)
}
// heavy-compute.worker.js
self.onmessage = (e) => {
const result = expensiveCompute(e.data)
self.postMessage(result)
}
3. 内存隔离（iframe）：
// 对于性能特别差的子应用，降级使用 iframe
const loadAppInIframe = (app) => {
const iframe = document.createElement('iframe')
iframe.src = app.entry
iframe.style.width = '100%'
iframe.style.height = '100%'
document.getElementById('container').appendChild(iframe)
}
// 卸载时销毁 iframe（释放内存）
const destroyIframe = () => {
iframe.remove()
iframe = null
}
4. 资源隔离（限流）：
// 限制子应用同时请求数
class RequestLimiter {
constructor(maxConcurrent = 6) {
this.maxConcurrent = maxConcurrent
this.currentCount = 0
this.queue = []
}
async request(url) {
if (this.currentCount >= this.maxConcurrent) {
await new Promise(resolve => this.queue.push(resolve))
}
this.currentCount++
try {
const response = await fetch(url)
return response
} finally {
this.currentCount--
if (this.queue.length > 0) {
this.queue.shift()()
}
}
}
}
const limiter = new RequestLimiter(3) // 限制3个并发
---
二、性能监控方案
1. 加载性能监控：
// qiankun 生命周期监控
registerMicroApps([{
name: 'app1',
entry: '//localhost:8081',
loader: (loading) => {
if (loading) {
window.__APP_LOAD_START__ = performance.now()
} else {
const loadTime = performance.now() - window.__APP_LOAD_START__
// 上报加载时间
reportMetric({
app: 'app1',
metric: 'load_time',
value: loadTime,
level: loadTime > 3000 ? 'error' : 'info'
})
}
}
}])
2. 运行时性能监控：
// FPS 监控
class FPSMonitor {
constructor() {
this.fps = 0
this.lastTime = performance.now()
this.frames = 0
}
tick() {
this.frames++
const now = performance.now()
if (now >= this.lastTime + 1000) {
this.fps = Math.round((this.frames * 1000) / (now - this.lastTime))
this.frames = 0
this.lastTime = now
// FPS 过低告警
if (this.fps < 30) {
reportPerformance({
type: 'low_fps',
fps: this.fps,
app: getCurrentApp()
})
}
}
requestAnimationFrame(() => this.tick())
}
}
const fpsMonitor = new FPSMonitor()
fpsMonitor.tick()
3. 内存监控：
// 监控子应用内存占用
const monitorMemory = () => {
if (performance.memory) {
const { usedJSHeapSize, totalJSHeapSize } = performance.memory
const usage = (usedJSHeapSize / totalJSHeapSize * 100).toFixed(2)
// 内存占用过高告警
if (usage > 90) {
reportPerformance({
type: 'high_memory',
usage,
app: getCurrentApp()
})
}
}
}
setInterval(monitorMemory, 10000) // 每10秒检测
4. 长任务监控：
// PerformanceObserver 监控长任务
const observer = new PerformanceObserver((list) => {
for (const entry of list.getEntries()) {
// 超过50ms的任务被认为是长任务
if (entry.duration > 50) {
reportPerformance({
type: 'long_task',
duration: entry.duration,
app: getCurrentApp(),
startTime: entry.startTime
})
}
}
})
observer.observe({ entryTypes: ['longtask'] })
5. 接口性能监控：
// 拦截子应用请求，监控接口性能
const originalFetch = window.fetch
window.fetch = async (...args) => {
const startTime = performance.now()
const url = args[0]
try {
const response = await originalFetch(...args)
const duration = performance.now() - startTime
// 慢接口告警（> 3秒）
if (duration > 3000) {
reportPerformance({
type: 'slow_api',
url,
duration,
app: getCurrentApp()
})
}
return response
} catch (error) {
reportPerformance({
type: 'api_error',
url,
error: error.message,
app: getCurrentApp()
})
throw error
}
}
6. 用户体验监控（Web Vitals）：
import { getCLS, getFID, getFCP, getLCP, getTTFB } from 'web-vitals'
// 监控核心性能指标
getCLS(metric => reportMetric('CLS', metric.value)) // 累计布局偏移
getFID(metric => reportMetric('FID', metric.value)) // 首次输入延迟
getFCP(metric => reportMetric('FCP', metric.value)) // 首次内容绘制
getLCP(metric => reportMetric('LCP', metric.value)) // 最大内容绘制
getTTFB(metric => reportMetric('TTFB', metric.value)) // 首字节时间
---
三、降级方案
1. 超时降级：
// 子应用加载超时，显示降级UI
const loadAppWithTimeout = async (app, timeout = 10000) => {
return Promise.race([
loadMicroApp(app),
new Promise((_, reject) => {
setTimeout(() => reject(new Error('加载超时')), timeout)
})
]).catch((error) => {
// 降级：显示静态页面
showFallbackUI(app.name)
reportError({
app: app.name,
type: 'load_timeout',
error
})
})
}
const showFallbackUI = (appName) => {
const container = document.getElementById('container')
container.innerHTML = `
<div class="fallback">
<h2>${appName} 加载失败</h2>
<button onclick="retryLoad()">重试</button>
<button onclick="useBasicVersion()">使用基础版本</button>
</div>
`
}
2. 错误降级：
// 子应用运行时错误，降级处理
addGlobalUncaughtErrorHandler((event, app) => {
const errorCount = getErrorCount(app.name)
if (errorCount > 3) { // 错误次数超过3次
// 降级：卸载子应用
unmountMicroApp(app.name)
// 显示降级UI
showDegradedUI(app.name)
// 告警
alertDevelopers({
app: app.name,
reason: '错误率过高，已自动降级'
})
}
})
3. 性能降级：
// 根据性能指标动态降级
const performanceGrade = getPerformanceGrade()
if (performanceGrade === 'poor') {
// 降级策略
- 禁用动画
- 减少轮询频率
- 延迟加载非核心模块
- 降低渲染精度
registerMicroApps([{
name: 'app1',
props: {
enableAnimation: false, // 禁用动画
pollingInterval: 10000, // 轮询间隔延长
lazyLoad: true // 懒加载
}
}])
}
4. 设备降级：
// 低端设备降级
const isLowEndDevice = () => {
// 内存小于4GB
const memory = navigator.deviceMemory
if (memory && memory < 4) return true
// CPU核心数少于4
const cores = navigator.hardwareConcurrency
if (cores && cores < 4) return true
return false
}
if (isLowEndDevice()) {
// 降级：使用轻量版本
registerMicroApps([{
name: 'app1',
entry: 'https://app1-lite.example.com' // 轻量版
}])
}
---
四、容错方案
1. 错误边界（React）：
// 主应用错误边界
class MicroAppErrorBoundary extends React.Component {
constructor(props) {
super(props)
this.state = { hasError: false, error: null }
}
static getDerivedStateFromError(error) {
return { hasError: true, error }
}
componentDidCatch(error, errorInfo) {
// 上报错误
reportError({
app: this.props.appName,
error: error.toString(),
errorInfo
})
// 尝试重新加载
this.retryCount = (this.retryCount || 0) + 1
if (this.retryCount < 3) {
setTimeout(() => {
this.setState({ hasError: false })
this.forceUpdate()
}, 2000)
}
}
render() {
if (this.state.hasError) {
return (
<div>
<h2>子应用出错了</h2>
<button onClick={() => location.reload()}>刷新页面</button>
</div>
)
}
return this.props.children
}
}
2. 资源加载容错：
// 子应用 JS 加载失败，尝试备用CDN
const loadScriptWithFallback = (src, fallbackSrc) => {
return new Promise((resolve, reject) => {
const script = document.createElement('script')
script.src = src
script.onload = resolve
script.onerror = () => {
console.log('主CDN加载失败，尝试备用CDN')
// 移除失败的script
script.remove()
// 尝试备用CDN
const fallbackScript = document.createElement('script')
fallbackScript.src = fallbackSrc
fallbackScript.onload = resolve
fallbackScript.onerror = reject
document.head.appendChild(fallbackScript)
}
document.head.appendChild(script)
})
}
// 使用
loadScriptWithFallback(
'https://cdn1.example.com/app1.js',
'https://cdn2.example.com/app1.js' // 备用CDN
)
3. 接口容错：
// 子应用接口失败，重试机制
const fetchWithRetry = async (url, options = {}, retries = 3) => {
for (let i = 0; i < retries; i++) {
try {
const response = await fetch(url, options)
if (response.ok) {
return response
}
} catch (error) {
if (i === retries - 1) throw error
// 指数退避
await new Promise(r => setTimeout(r, Math.pow(2, i) * 1000))
}
}
}
4. 状态容错：
// 子应用状态异常，自动恢复
const recoverState = (app) => {
try {
// 尝试从 localStorage 恢复状态
const savedState = localStorage.getItem(`${app}_state`)
if (savedState) {
return JSON.parse(savedState)
}
} catch (error) {
// 恢复失败，使用默认状态
return getDefaultState()
}
}
5. 自动重启：
// 子应用崩溃自动重启
let crashCount = 0
const MAX_CRASH_COUNT = 3
addGlobalUncaughtErrorHandler((event, app) => {
crashCount++
if (crashCount < MAX_CRASH_COUNT) {
// 自动重启
setTimeout(() => {
unmountMicroApp(app.name)
loadMicroApp({
name: app.name,
entry: app.entry,
container: app.container
})
console.log(`子应用 ${app.name} 已自动重启`)
}, 1000)
} else {
// 重启次数过多，放弃
showFatalError(app.name)
}
})
---
五、性能优化建议
1. 子应用优化：
✅ 代码分割（React.lazy、Vue异步组件）
✅ 按需加载（路由懒加载）
✅ Tree Shaking（移除未使用代码）
✅ 压缩打包（Gzip、Brotli）
✅ CDN 加速
✅ 图片懒加载、压缩
✅ 减少依赖体积（使用 lodash-es、day.js）
✅ Service Worker 缓存
2. 主应用优化：
✅ 预加载核心子应用
✅ 虚拟滚动（大列表）
✅ 防抖节流（高频事件）
✅ Web Worker（耗时计算）
✅ CSS 隔离（避免样式冲突）
3. 通信优化：
✅ 减少跨应用通信频率
✅ 批量更新（合并多次setState）
✅ 使用 throttle/debounce
---
完整的性能治理体系：
┌─────────────────────────────────┐
│ 监控层（Monitoring） │
│ ├─ 加载性能（Load Time） │
│ ├─ 运行时性能（FPS、Memory） │
│ ├─ 接口性能（API Time） │
│ └─ 用户体验（Web Vitals） │
└────────────┬────────────────────┘
↓ 发现问题
┌─────────────────────────────────┐
│ 告警层（Alerting） │
│ ├─ 性能告警（超时、卡顿） │
│ ├─ 错误告警（崩溃、404） │
│ └─ 自动通知（钉钉、邮件） │
└────────────┬────────────────────┘
↓ 触发策略
┌─────────────────────────────────┐
│ 降级层（Degradation） │
│ ├─ 超时降级（静态页面） │
│ ├─ 错误降级（基础版本） │
│ ├─ 性能降级（减少动画） │
│ └─ 设备降级（轻量版） │
└────────────┬────────────────────┘
↓ 保障可用性
┌─────────────────────────────────┐
│ 容错层（Fault Tolerance） │
│ ├─ 错误边界（Error Boundary） │
│ ├─ 自动重试（Retry） │
│ ├─ 备用方案（Fallback） │
│ └─ 自动恢复（Recovery） │
└─────────────────────────────────┘
最终目标：
✅ 子应用问题不影响主应用
✅ 用户无感知降级
✅ 问题自动发现、自动降级、自动恢复
✅ 开发者及时收到告警