qiankun调试逻辑打开test环境时需要靠本地代理拦截子应用资源请求通过mock指定appKey让基座不去加载 test 环境打包好的子应用转而加载你本地跑的程序流程如下基座test远端应用本地子应用1.基座内置抽屉逻辑根据appkey拉去远程服务端产物2.远端子应用test 环境静态资源程序打包产物存在测试静态服务器正常流程基座直接 fetch 远端 entry。3.本地子应用: 本地npm dev,热更新未打包本地代码实时生效为什么要遵循本地代理 mock 切换 appKey的方式1本地代理作用qiankun 加载子应用通过fetch(entry)拉取html,浏览器同源策略限制当跨域基座直接访问本地子应用会报CORS失败加载白屏启动本地代理服务劫持基座发起的「子应用资源请求」原本请求https://静态服务器:xxx/index.html代理拦截后转发到http://localhost:xxxx/index.html让 test 基座以为还在请求测试环境静态资源实际打到你本地代码绕开跨域。2mock作用基座加载哪个子应用由 appKey 映射远端 entry 地址映射关系存在远端配置表Nacos / 门户配置文件但是开启本地代理后代理会拦截原test环境静态地址无法切换到本地代码所以需要mock本地当检测到指定的appkey开启本地调试后会吧该appkey对应的entry改成localhost本地地址3切换micro app key区分调试子应用门户工作台抽屉支持多子应用appKey 是基座匹配子应用的唯一标识不切换 key代理不知道要劫持哪一套静态资源只会固定拦截某一个子应用。qiankun搭建本地安装qiankun$ yarn add qiankun # 或者 npm i qiankun -S主应用中注册微应用import { registerMicroApps, start } from qiankun; // 注册所有子应用列表 registerMicroApps([ { name: react app, // 子应用唯一标识 你们业务里的 appKey entry: //localhost:7100, // 子应用入口地址html 地址 container: #yourContainer, // 渲染到基座哪个DOM容器 activeRule: /yourActiveRule, // 路由匹配规则路由命中自动加载 }, { name: vue app, entry: { scripts: [//localhost:7100/main.js] }, // 直接指定JS入口模式 container: #yourContainer2, activeRule: /yourActiveRule2, }, ]); // 启动 qiankun 微前端监听 start();生命周期钩子函数bootstrap仅初始化执行 1 次整个子应用生命周期只跑 1 次第一次打开抽屉加载子应用时执行后续关闭抽屉再重新打开不会再走 bootstrap直接走 mount。mount每次打开子应用都会执行渲染页面每一次打开抽屉 / 进入子应用都执行基座调用 loadMicroApp抽屉打开→ 执行 mount完成页面渲染。unmount每次关闭 / 销毁子应用执行清理资源update可选仅动态 loadMicroApp你们抽屉 openMicroDrawer才会触发只有基座用 loadMicroApp 动态加载抽屉才会触发全屏路由自动加载 registerMicroApps 不会执行 update。webpackentry入口从这里寻找所有依赖-output输出-loader转换器-plugin插件-mode打包模式output输出打包后文件输出目录、文件名配置dist 文件夹就是 output。qiankun学习qiankun架构qiankun分为主应用和子应用主应用主要负责登录权限菜单顶部导航左侧导航注册微应用决定加载哪个子应用主应用柜子 │ ├── 首页 ├── 用户中心 ├── 菜单 │ └── 内容区域抽屉 │ ├── 子应用A ├── 子应用B └── 子应用C子应用就像用户列表用户详情用户编辑按照业务进行划分每个子应用都有自己的路由主应用-子应用eg:http://localhost:7100/user/list在这个时候主应用看到location.pathname是/user/list 匹配activeRule/user 之后加载子应用将子应用渲染到div idsubapp/div最终页面体现为┌────────────────────┐│ Header │ ← 主应用├────────────────────┤│ Menu │ ← 主应用├────────────────────┤│ 用户列表 │ ← 子应用└────────────────────┘抽屉抽屉就是侧边弹出面板组件和弹窗 Modal 是一类但形态不一样Modal居中浮层覆盖页面Drawer抽屉从页面左侧 / 右侧滑出来一块面板不会完全盖住背景主页面。主应用负责打开哪个抽屉即activeRule决定当前加载哪个抽屉而抽屉里面具体有什么是子应用需要关注的事情Drawer 和微应用的嵌套关系可以理解为主应用页面└── Drawer负责显示container└── 微应用挂载节点└── 功能子应用└── Router 根据url找页面└── 创建表单页面例如系统采用 qiankun 微前端架构。有一个业务子应用 A。有一个功能子应用 B。功能子应用 B 中有一个「创建表单页面」。用户在业务子应用 A 中点击按钮。A 打开一个 Drawer抽屉。同时切换到 B 的指定路由。qiankun 根据路由加载 B。B 的 Router 匹配到「创建表单页面」。创建表单组件最终渲染到 Drawer 中。实际执行流程是这样的维度activeRule registerMicroApps抽屉 loadMicroApp /openMicroDrawer触发方式浏览器地址栏路由自动触发代码手动调用弹窗不改变主路由路由来源主应用 location.pathname基座手动传props.homePath路由模式主应用 WebHistory子应用 MemoryHistory 内存路由容器页面固定 #container运行时动态生成 props.container使用场景全屏页面跳转侧边抽屉、弹窗内嵌子应用根据路由渲染组件微应用有多种路由模式react,angular,vue这三种路由方式都支持hash与history模式activeRule是 registerMicroApps 静态注册微应用时的路由激活匹配规则。qiankun使用location.pathname做activeRule时不同路由模式下 URL 的表现区别也有所不同http://localhost:7100/app#/user ↑ ↑ pathname hashhistory模式createWebHistory(/app)路由体现为如下此时在location.pathname的体现为/app/app/user/app/detail/1主应用 http://localhost:7100/ 进入微应用首页 http://localhost:7100/app 微应用跳转用户页 http://localhost:7100/app/user 微应用跳转详情页 http://localhost:7100/app/detail/1hash模式createWebHashHistory()路由信息放在location.hash中对于hash模式来说qiankun 用 pathname 识别哪个微应用微应用自己用 hash 识别内部页面location.pathnameapplocation.hash#/user