钉子的生活日记
文章目录

Qiankun 微前端学习笔记

适合目标：掌握 Qiankun 的体系化设计、single-spa 思想、接入流程和工程化使用方式。
学习定位：这一份偏“经典方案、运行时托管、生命周期与沙箱”。
学习原则：先理解它为什么成熟，再理解它为什么也有接入成本。

目录

  1. Qiankun 是什么
  2. 为什么 Qiankun 曾经非常主流
  3. 核心原理
  4. 接入流程
  5. 生命周期与沙箱
  6. 路由、样式、通信
  7. 进阶实践
  8. 常见问题
  9. 适用场景
  10. 面试考点
  11. 一页总结

1. Qiankun 是什么

Qiankun 是一个基于 single-spa 思想扩展出来的微前端框架。
它比较经典，也很适合用来建立微前端的体系化认知。

你可以把它理解成：

主应用通过路由激活不同子应用，并托管它们的加载、挂载、卸载和隔离。

2. 为什么 Qiankun 曾经非常主流

2.1 它解决了哪些关键问题

  1. 子应用按路由激活
  2. HTML Entry 资源接入
  3. JS 沙箱
  4. 样式隔离
  5. 生命周期标准化

2.2 为什么它适合学习

即使你最后不一定选择 Qiankun，学习它仍然很有价值，因为它能帮你建立一整套微前端核心模型：

  1. 注册应用
  2. 激活规则
  3. 生命周期
  4. 沙箱
  5. 样式隔离

3. 核心原理

3.1 基于 single-spa 的调度模型

主应用维护一个应用列表，每个子应用有：

  1. 名称
  2. 入口地址
  3. 激活规则
  4. 挂载容器

当路由命中激活规则时，Qiankun 会触发对应子应用的生命周期。

3.2 HTML Entry

Qiankun 的一个重要思路是 HTML Entry。
它不只是加载一个 JS 文件，而是把子应用入口 HTML 作为资源入口解析，再处理：

  1. script
  2. style
  3. link
  4. 执行上下文

这让子应用整体接入更自然，但也意味着你要处理资源路径和执行顺序问题。

3.3 沙箱

Qiankun 的沙箱主要解决子应用执行时对全局环境的污染问题。
你需要重点理解：

  1. 为什么要代理 window
  2. 为什么要恢复全局副作用
  3. 为什么卸载后要还原环境

3.4 样式隔离

常见思路包括：

  1. 作用域隔离
  2. 特定模式下的 Shadow DOM

但工程上依然不能完全放弃 CSS 规范治理。

4. 接入流程

4.1 主应用注册子应用

概念性伪代码：

registerMicroApps([
  {
    name: 'app1',
    entry: '//localhost:3001',
    container: '#subapp-container',
    activeRule: '/app1'
  }
])

start()

这里最重要的是 4 个配置：

  1. name
  2. entry
  3. container
  4. activeRule

4.2 子应用需要暴露生命周期

Qiankun 通常要求子应用暴露类似：

  1. bootstrap
  2. mount
  3. unmount

某些场景还可能有 update。

这意味着子应用需要做一定改造，尤其是老项目。

4.3 路由配置

子应用要明确自己的路由基座，否则经常会遇到：

  1. 页面跳转错乱
  2. 刷新丢失
  3. 静态资源路径异常

5. 生命周期与沙箱

5.1 生命周期怎么理解

bootstrap

应用初始化，只做一次性准备。

mount

真正把子应用挂到页面容器上。

unmount

卸载子应用，清理页面和副作用。

update

部分场景下用于应用更新或主应用传值变化。

5.2 为什么生命周期重要

因为微前端不是简单“打开页面”，而是：

一个应用会被反复挂载和卸载。

如果生命周期没处理好，就会出现：

  1. 重复监听
  2. 内存泄漏
  3. 页面残影
  4. 状态脏数据

5.3 沙箱治理对象

  1. 全局变量
  2. 定时器
  3. 事件监听
  4. DOM 副作用
  5. 路由状态

6. 路由、样式、通信

6.1 路由

建议：

  1. 主应用只控制激活规则
  2. 子应用自己维护内部路由
  3. 主子路由前缀必须提前规划
  4. 刷新和深链访问必须单测或联调验证

6.2 样式

不要以为框架做了隔离就完全没问题。
工程上依然建议：

  1. CSS Module、BEM、命名空间等手段并用
  2. UI 组件库主题不要乱写全局覆盖
  3. 全局 reset 做统一托管

6.3 通信

推荐模式：

  1. 主应用维护全局上下文
  2. 子应用消费少量公共信息
  3. 子应用尽量自治
  4. 跨应用协作优先走后端接口

7. 进阶实践

7.1 预加载

对高频子应用做预加载可以改善体验，但要注意：

  1. 不要无脑全量预加载
  2. 按角色和访问频率预加载
  3. 监控预加载收益

7.2 公共依赖复用

要关注：

  1. React/Vue 是否重复打包
  2. 组件库是否重复引入
  3. 工具函数库是否重复下载

7.3 统一错误监控

推荐埋点：

  1. 加载失败
  2. 生命周期异常
  3. 白屏
  4. 路由失败
  5. JS 异常

7.4 工程规范

需要一套明确规范：

  1. 应用接入模板
  2. 生命周期模板
  3. 路由前缀约定
  4. 构建产物规范
  5. 发布与回滚规范

8. 常见问题

8.1 子应用静态资源加载失败

通常看：

  1. publicPath
  2. 构建产物地址
  3. CDN 或网关映射

8.2 子应用卸载后仍然残留

通常看：

  1. 根节点是否清空
  2. 监听是否释放
  3. 定时器是否清理

8.3 子应用切换变慢

通常看：

  1. 是否每次都重新拉资源
  2. 是否缺少预加载
  3. 是否有重复初始化

8.4 开发环境调试麻烦

改进方式：

  1. 统一 dev 端口
  2. 主应用提供注册中心
  3. 环境变量和代理统一

9. 适用场景

9.1 适用

  1. 平台型主应用
  2. 业务子系统按路由切分
  3. 团队愿意接受一定接入规范
  4. 希望体系化治理微前端

9.2 不适用

  1. 极度追求低接入成本的老系统拼装
  2. 更偏模块联邦而非整应用托管的体系

10. 面试考点

10.1 Qiankun 的核心机制是什么

答题要点：

  1. 基于 single-spa 的调度
  2. HTML Entry 加载子应用
  3. 生命周期托管
  4. JS 沙箱与样式隔离

10.2 为什么子应用要暴露生命周期

因为主应用需要在路由切换时精确控制子应用何时初始化、何时渲染、何时销毁。

10.3 Qiankun 最大的工程挑战是什么

  1. 老项目改造
  2. 路由 base 统一
  3. 资源路径治理
  4. 生命周期副作用清理

10.4 Qiankun 和 Module Federation 有什么区别

Qiankun 偏整应用托管和运行时编排；
Module Federation 偏远程模块共享和工程体系拆分。

11. 一页总结

11.1 Qiankun 的关键词

single-spa、HTML Entry、生命周期、沙箱、主应用编排。

11.2 适合谁

  1. 想建立完整微前端体系的团队
  2. 平台型主应用场景
  3. 已有明显路由分发结构的系统

11.3 记忆口诀

先注册、再激活、靠生命周期托管、靠沙箱控制污染。