1. 先理清楚qiankun里到底有哪几类“跳转”1.1 四类跳转的直观场景在做微前端改造之前大部分人遇到的“跳转”就是一个单页应用里路由跳来跳去。但一旦上了qiankun事情就没那么简单了。你面前会出现四个完全不同的跳转场景主应用自己内部的页面跳转比如主应用的首页跳到主应用的管理中心主应用跳到某个微应用比如主应用菜单点击后进入订单微应用微应用内部自己的页面跳转这个其实和普通单页应用没区别微应用跳到主应用或者微应用A跳到微应用B我用一个真实项目举例有一个后台系统主应用负责登录、权限、统一布局和导航菜单子应用有订单中心、用户中心、数据中心三个独立的Vue工程。用户登录后从主应用的仪表盘点“订单管理”然后进入订单微应用查看详情再点“该用户的更多信息”直接跳转到用户中心微应用。这一套流程里主应用跳子应用、子应用跳主应用、子应用互跳全都有涉及。如果你只会在主应用里用router.push跳微应用而没处理好子应用之间的互联后面业务复杂起来会非常痛苦。因为qiankun本身不是一个路由框架它只管微应用加载和卸载并不帮你处理“应用之间怎么导航”。所有跨应用的跳转策略都需要你在启动qiankun之前就设计好。1.2 跳转之前必须搞懂的路由模式问题我在处理跳转问题时发现90%的跳转异常都出在路由模式不统一。qiankun官方文档里主应用干活用的是history模式但子应用有的项目为了省事会采用hash模式。这两种模式混用时跳转的逻辑会不太一样轻则不按预期工作重则直接404。先说结论如果主应用用的是history模式子应用最好也统一用history模式。如果主应用是hash模式你很难用纯history方式去拼接一个能直接访问的URL比如主应用是hash路由你直接去微应用里用this.$router.push(/order)是可行的但你想通过浏览器地址栏拼一个完整地址来打开微应用页面就有很多坑后面我会讲到。再看qiankun的匹配规则。主应用注册微应用时会配置activeRule比如/order。那如果你在地址栏输入https://example.com/order/detail/123qiankun就会判定该加载订单微应用。子应用收到URL后根据自己内部的Vue Router再解析/detail/123。这里有个非常重要的细节子应用必须设置base为/order否则它会把/detail/123当成根路径去匹配结果出来一个找不到路由的白屏页面。另外qiankun在加载微应用时会给子应用注入一条publicPath但在某些场景下比如子应用里用了懒加载组件切换路由后组件路径会错乱也会表现为“跳转空白”。看起来是跳转问题实际上是Webpack打包配置问题。所以排查问题时先统一路由模式再检查base配置最后看构建产物路径。这三件事是跳转的底层前提一件都不能少。2. 主应用内部跳转最容易翻车的历史模式问题2.1 主应用用Vue Router时怎么跳如果主应用是一个Vue 2工程使用Vue Router 3.x的history模式主应用内部跳转本身没有任何特殊之处正常写// 主应用组件内 this.$router.push(/home) this.$router.push(/about)但你有没有想过这样一个问题当主应用当前停留在一个微应用的页面里URL可能是https://example.com/order/detail/123。这时候你在主应用的某个公共组件比如顶部全局搜索框里执行this.$router.push(/home)会发生什么如果你没有在beforeEach守卫里做特殊处理这个跳转会触发qiankun路由匹配。因为URL从/order/xxx变成了/homeqiankun会判定当前不匹配/order于是卸载订单微应用加载主应用的/home页面。这是符合预期的。但如果你在微应用页面内点击了主应用的一个“返回首页”按钮而这个按钮用的不是主应用暴露的路由实例而是直接修改window.location.href /home那就会触发整页刷新。整页刷新在微前端架构下不是不行但会丢失微应用的内存状态权限信息如果存在sessionStorage里倒是没事但如果存在Vuex内存变量里就得重新拉取。所以我后来在主应用菜单里统一封装了一个跳转方法不同场景自动选择router.push还是window.history.pushState。还有一点主应用如果用了Vue Router 4Vue 3工程方法和Vue Router 3几乎一样但在qiankun的场景下要注意history.pushState和路由实例可能会出现不同步。如果你在某个时刻手动改了URL比如通过history.pushStateVue Router内部并不知道URL变了需要手动执行路由实例的匹配逻辑否则页面不会更新。2.2 history模式下主应用页面跳转与微应用的坑主应用在当前停留微应用页面时如果直接在主应用代码里写this.$router.push(/some-main-page)大部分情况下是可以工作的但有一个很常见的坑主应用路由的beforeEach守卫里如果写了类似“判断是不是微应用路径然后next(false)”的逻辑跳转就会被拦截。我之前还遇到过另一个问题主应用里放了多个微应用微应用A的activeRule是/app-a微应用B的activeRule是/app-b。我在主应用页面里点击菜单切换到微应用B如果用的是this.$router.push(/app-b/home)qiankun能正确匹配并加载微应用B。但如果先进入了/app-b/home/123这样一个二级路径再切回/app-bqiankun会发现URL变回/app-b可能会重新触发微应用B的加载流程而不是只做一次路由切换。这点非常关键。qiankun的activeRule匹配的是“前缀”。当URL前缀从/app-b/home/123变为/app-b时前缀/app-b仍然存在qiankun会认为微应用B仍然激活不会卸载也不会重新加载。但如果你是从/app-b切到/app-a前缀变了qiankun会先卸载B再加载A。卸载过程是异步的如果你的代码里在router.push之后立刻去操作DOM或查询元素有可能会拿到旧应用残留的内容或者报出“node is not found”之类的错误。所以主应用内做跨应用切换时最好用一个包装方法里面加入合理的异步延时或afterUnload回调等qiankun完成卸载和加载后再执行后续逻辑。我给的兜底方案是// 主应用暴露一个全局跳转方法 function switchTo(appPath) { const loadingApp microApps.find(app appPath.startsWith(app.activeRule)) if (loadingApp loadingApp.status NOT_LOADED || loadingApp.status UNMOUNTED) { // 如果目标应用还没加载先加载再跳转 loadMicroApp(loadingApp).then(() { window.history.pushState({}, , appPath) }) } else { window.history.pushState({}, , appPath) router.push(appPath) } }这个思路可以应对多数主应用内跨应用切换的场景但细节上还需依据你的qiankun版本来调整事件监听方式。如果你用的是qiankun 2.xloadMicroApp是可用方法如果用的是1.xAPI会有些出入需要参考对应版本文档。3. 主应用与微应用之间的跳转最常用的三种手段3.1 主应用跳转到微应用菜单点击触发的标准操作最常见的一种场景就是主应用的侧边栏菜单点击后跳转到某个微应用的首页。我推荐的做法并不复杂菜单项数据里为每个菜单配置一个path字段比如/order/home、/user/list点击菜单时直接调用主应用的路由实例router.push(menuItem.path)qiankun根据activeRule自动加载对应微应用这个方案之所以推荐是因为它完全依赖qiankun的“路由驱动”机制不需要手动管理子应用的生命周期。主应用只需要在注册微应用时把activeRule、entry、container配置好registerMicroApps([ { name: order-app, entry: //localhost:3001, container: #micro-app-container, activeRule: /order }, { name: user-app, entry: //localhost:3002, container: #micro-app-container, activeRule: /user } ]) start()之后点击“订单管理”菜单执行router.push(/order/home)qiankun就会自动匹配到/order前缀加载订单微应用并将/order/home这个URL传给子应用。子应用内部的路由再根据base/order解析出真正的页面。3.2 微应用跳转到主应用通过props传递跳转能力微应用不能直接操作主应用的路由实例因为qiankun在隔离环境里运行子应用子应用拿不到主应用Router上下文。那子应用想跳回主应用怎么办我见过很多团队的做法是让子应用直接改window.location.href这确实能跳但代价是整页刷新。在表单填写了一半、弹窗开着的情况下整页刷新用户会崩溃。更优雅的做法是在registerMicroApps时通过props向子应用传递一个跳转方法registerMicroApps([ { name: order-app, entry: //localhost:3001, container: #micro-app-container, activeRule: /order, props: { navigateToMain: (path) { window.history.pushState({}, , path) // 手动通知路由实例处理URL变化 router.push(path) } } } ])子应用在自己的main.js入口处接收props然后挂载到Vue原型或全局状态里export async function mount(props) { // props里就有主应用传过来的navigateToMain Vue.prototype.$navigateToMain props.navigateToMain // 或存入Vuex store.commit(SET_NAVIGATE_TO_MAIN, props.navigateToMain) const instance new Vue({ router, store, render: h h(App) }) instance.$mount(#app) }然后在子应用的任意组件里就可以这样跳回主应用this.$navigateToMain(/home)我实际用下来的体验是这个方案比window.location.href要好很多因为它是纯前端路由级别的跳转不走整页刷新主应用切换回/home页面子应用会正常卸载内存中也不会残留子应用未销毁的事件监听器。3.3 子应用内部正常路由跳转和主应用无感子应用内部页面之间的跳转其实和普通单页应用没有任何区别。你在订单微应用里从订单列表/order/list跳到订单详情/order/detail/123直接用自己Vue Router的router.push就好。但有一点要注意子应用内部跳转时URL会发生真实变化从/order/list变成/order/detail/123。这时候qiankun的主应用路由并不会感知到URL变化因为qiankun只关心前缀是否匹配所以不会触发重新加载子应用的操作。这没问题。可一旦用户在子应用内刷新页面浏览器会重新加载整个HTML主应用会启动qiankun看到URL是/order/detail/123匹配到订单微应用再次加载子应用。整个过程是完整的。所以子应用内部路由跳转不需要额外处理。真正麻烦的是刷新后404的问题。如果你部署后没有把Nginx的try_files配置成try_files $uri $uri/ /index.html刷新一个/order/detail/123深链接时会直接404因为服务器上根本没有这个物理路径只有根目录的index.html。我遇到过很多次明明本地开发一切正常部署到测试环境一刷新就白屏或404。排除方法很简单先看是不是Nginx配置漏了再看主应用加载够不够快。3.4 利用全局状态配合跳转在3.2里我们用了props传递跳转方法这已经够用了。但有一种更灵活的做法是通过qiankun的GlobalState来配合跳转。// 主应用里初始化全局状态 initGlobalState({ currentUser: null, lastPath: /home })子应用通过onGlobalStateChange监听状态变化在某个状态变更后执行跳转actions.onGlobalStateChange((state, prev) { if (state.gotoPath state.gotoPath ! prev.gotoPath) { router.push(state.gotoPath) } })这个方案的好处是“解耦”。主应用不需要把跳转方法暴露给子应用子应用也不需要依赖主应用的方法只要大家约定好一个状态字段即可。缺点是间接层变多容易造成状态满天飞调试起来稍微费劲。如果只是解决主微应用跳转问题props传递方法更直接如果还要顺带传一些业务数据那GlobalState确实是个不错的选择。4. 微应用之间的互相跳转核心思路是“借道主应用”4.1 微应用A跳微应用B的最可靠方案微应用A要跳转到微应用B最直接的想法是“A直接改URL到B的地址”。比如window.location.href /user/list这样确实能跳到微应用B而且qiankun会卸载A、加载B。但代价是整页刷新。另一个变体方案是用window.history.pushStatewindow.history.pushState({}, , /user/list)这样URL变了qiankun如何感知qiankun内部监听了popstate事件但pushState并不会触发popstate。所以如果你只执行pushState而不做其他操作qiankun很可能不会去加载微应用B页面停留在A而URL却是B的地址——看起来像是A里出了一个Bug。所以最可靠的方案是微应用A通过props里的跳转方法先跳回主应用再由主应用路由跳转到微应用B。用代码表示就是// 子应用A内部拿到主应用传入的跨应用跳转方法 this.$navigateToMain(/user/list)主应用的navigateToMain方法接收到/user/list执行router.push(/user/list)qiankun看到URL前缀变成/user自然卸载A、加载B。整个过程不会整页刷新。如果还是想从A直接调B不走主应用“中转”也可以直接在主应用里给子应用传一个navigateToApp方法里面先去判断目标应用是否已加载再执行加载和跳转。但这个方法实现起来略微复杂需要有主应用Vue Router实例配合。所以我建议没有特殊需求的话统一用“借道主应用”方案逻辑清晰、容易排查。4.2 带参数跳转和回退注意事项微应用A跳微应用B通常还要带参数比如从订单详情页跳到用户详情的ID。参数放哪里放在URL路径里/user/detail/123简单直接刷新不丢参数放在URL query里/user/detail?id123也还直观但有些场景下会污染URL放在GlobalState里不污染URL但刷新后会丢我一般建议重要的业务参数放URL路径或query里。经历过一次痛苦的调试后我就彻底放弃了把已选商品、订单号这类核心参数塞在GlobalState里的想法——用户一刷新参数全没了页面直接空白。跳转后怎么回退比如从订单微应用跳到了用户微应用用户点浏览器“返回”按钮希望回到订单详情页。这里有个关键点如果用的是router.push浏览器历史栈里会多一条记录返回是可以回到上一页的。如果用的是window.location.href整页跳转返回时会重新加载之前的页面微应用的加载状态会被重建但页面也勉强能回来。但如果你的子应用A是通过router.replace这种方式跳转的历史栈被替换了返回就不会回到A页面。所以在设计跨应用跳转时要想清楚是“暂时性的跳转”应该可以返回还是“永久性的切换”不需要返回。两种语义对应push和replace别搞混。4.3 子应用内绝对路径跳转和相对路径跳转的差异在qiankun里子应用内部跳转时Vue Router的base决定了路由解析的根路径。比如你在子应用B里base是/user那么this.$router.push(/detail/123)实际浏览器URL变化是/user/detail/123。这里写的是“绝对路径”但它是在子应用的base之上拼的不是从根域名计算的。严格来说Vue Router内部会自动把base前缀加上所以最终URL看起来是从根开始。如果你写的是相对路径this.$router.push(detail/123)那会基于当前路由往下拼。如果当前是/user/list就是/user/list/detail/123。很多初学者在这里踩坑明明想跳详情页出来的URL是/user/list/detail/123再刷新就404。所以“子应用内跳转”尽量写绝对路径避免路径嵌套污染。我在qiankun项目中有一条强制约定所有子应用内部跳转路径必须以/开头并携带完整子应用内部路径比如/detail/123配合base拼成完整主URL。这条约定我一直沿用到现在跨应用跳转也从没再出过路径嵌套问题。5. 路由模式统一与URL直接访问的处理方案5.1 地址栏直接输入子应用URL的兼容处理你是否有过这样的体验在地址栏直接输入https://example.com/order/detail/123期望直接进入订单微应用的详情页。在纯前端开发环境里敲回车后浏览器会向服务器发起请求如果服务器没有配置正确的try_files大概率返回404。即便返回了index.html主应用启动后qiankun会去加载订单微应用子应用内部再解析/order/detail/123。所以要实现“地址栏直接输入子应用URL并正常打开”需要三层都给力Nginx或服务器配置所有路径都回退到index.html这一步很多团队会漏qiankun注册配置子应用activeRule与URL前缀一致子应用路由base必须设置为activeRule对应的前缀只要这三层全对地址栏直接输入任意子应用深链接都能正常打开。我自己在排查“为什么我直接访问URL打不开子应用”时通常按照这个顺序检查基本能立刻定位问题层次。5.2 Vue Router / React Router 内部跳转与浏览器URL变化的关系很多人会混淆Vue Router内部跳转和浏览器URL的关系。简单理解Vue Router的push底层就是调用history.pushState只是后面还多做了“路由匹配并重新渲染组件”这件事。qiankun的跳转驱动本身依赖浏览器URL前缀所以只要你通过任何方式让URL前缀变成某个子应用的activeRuleqiankun就有机会触发加载逻辑。但有一个前提是qiankun要能“听到”URL的变化。如果只是window.history.pushStateqiankun没监听这个事件就难以自动触发加载。有人会问那为什么qiankun官方示例里主应用用router.push就能正常跳转子应用因为Vue Router的push在执行时不仅改了URL还在内部通过popstate等机制触发route更新而qiankun监听了路由变化相关事件实际上监听的是popstate严格来说Vue Router变更时并不会触发popstate。那主应用是怎么感知的实际上qiankun内部对路由变化的感知是通过监听popstate和pushState方法重写等方式实现的。在某次qiankun迭代中已经对pushState做了方法包裹所以主应用模块里通过history.pushState触发URL变化时qiankun能感知。这也是为什么在子应用里直接执行window.history.pushState不一定稳妥的原因——子应用运行在隔离环境里它的window很多时候并非主应用的原生windowqiankun对它的处理跟主应用不太一样。所以别在子应用里手动操作history除非你很清楚自己在做什么。5.3 基于hash模式跳转的兼容思路有些旧项目子应用一直用的是hash模式比如URL是https://example.com/#/order/detail/123。这种模式下qiankun匹配activeRule时会有些特殊。因为hash部分不会发送到服务器所以服务器不用担心404但qiankun的activeRule匹配的是window.location.pathname和window.location.hash的组合官方默认支持hash模式匹配。如果你子应用用的是hash模式主应用想跳过去URL应该是https://example.com/#/order/detail/123子应用的base可能是/因为它所有路由都挂在hash后面。这种情况下跨应用跳转时要注意拼URL的格式必须是#/order/...而不是直接改pathname。简单说hash模式下的跳转更“宽容”但我不建议主应用和子应用混用两种模式因为排查问题时要时刻想着现在是基于hash还是history心智负担太重。6. 我踩过的那些跳转大坑与排查实录6.1 跳转后白屏但控制台没有任何报错这是微前端跳转问题里最常遇到、也最让人抓狂的现象。URL变了子应用没加载出来白屏控制台干干净净。我第一次遇到时排查了很久最后发现是子应用挂载容器被销毁了但没有在qiankun要求的时间里重新创建。qiankun的container如果指定的是#micro-app-container主应用在进行路由切换时如果误把这个容器对应的DOM节点删掉或隐藏子应用就找不到挂载点。还有一种情况主应用给子应用传了props子应用等待props异步获取权限数据权限数据还没回来页面就处于空白状态。我见过团队把等待弹窗做成一张空白页用户看起来就是白屏。排查时可以这样验证在地址栏手动刷新子应用URL如果能正常加载说明问题跟跳转逻辑无关而是跳转过程中少了某些初始化步骤。6.2 子应用可以打开但刷新就404这个问题前面提过多次这里补充一个更容易被忽视的点很多团队的主应用和微应用其实是部署在同一个域名下的不同路径比如主应用在/订单微应用在/order/用户微应用在/user/。部署时Nginx配置应该是location /order { try_files $uri $uri/ /order/index.html; } location /user { try_files $uri $uri/ /user/index.html; } location / { try_files $uri $uri/ /index.html; }如果Nginx把/order目录单独托管而try_files没有回退到/order/index.html而是回退到/index.html那点击子应用内部路由后刷新会先请求主应用HTML主应用再根据URL去加载微应用大概率也能成功但如果主应用和子应用是通过不同构建流程打包的子应用的资源路径相对于主应用根路径会有问题表现还是404或资源加载不了。所以部署层面的try_files必须按“子应用目录独立回退”配置。6.3 子应用跳转主应用后主应用组件不更新有时从微应用跳到主应用页面URL正确主应用壳子出来了但那个页面的组件数据没有重新加载。原因是主应用路由组件复用了Vue的beforeRouteEnter或created钩子不会再次执行。需要在主应用里对路由跳转做统一处理监听路由变化并重新拉取数据。比如watch: { $route() { this.fetchData() } }这样从任意微应用跳回主应用都能保证数据刷新。这个看起来是微前端跳转问题实际上是单页应用本身的路由复用问题但在微前端场景下更容易暴露出来因为微应用和主应用之间的数据传递太容易让人忽略“主应用页面也需要更新”这件事。6.4 使用全局状态跳转导致的状态不同步用GlobalState做跳转时最常见的问题是A应用设置了gotoPathB应用监听这个字段去跳转但是A应用里可能同时设置了其他字段B应用把整个state都拿到了却不知道该听谁的。我的建议是约定一个专门的跳转协议字段// 主应用初始化全局状态 initGlobalState({ navigation: { path: , query: , timestamp: 0 // 保证每次跳转都是新的 } })B应用监听到navigation.timestamp变化就去解析path和query并跳转。加时间戳是为了防止同一个URL连续跳两次时不触发变更。这种方案我用下来比裸传一个字符串字段可靠很多至少不会出现重复跳转或漏跳转。6.5 子应用loaded但不显示路由匹配没执行还有一次微应用加载了mount生命周期也执行了但页面空白。最后发现是子应用的base没配对的锅。qiankun把URL设置为/order/detail/123但子应用Vue Router的base配置成了/Vue Router去匹配/detail/123时怎么都对不上路由表。因为在子应用的路由表里根本没有/detail/123这种根路径开头的路径它的路由路径是/order/detail/123或者配了嵌套路径。解决方法是把子应用Vue Router的base设置为qiankun的activeRuleconst router new VueRouter({ base: window.__POWERED_BY_QIANKUN__ ? /order : /, mode: history, routes })这段代码在qiankun官方文档里也有示例但在实际项目里很多人要么没看到要么写了但写错了。我一直强调子应用单独开发时要保持base为/在qiankun环境里要动态切到activeRule前缀。用window.__POWERED_BY_QIANKUN__做判断是最稳妥的做法。6.6 qiankun 2.x与单应用模式下DevServer的跨域配置开发环境下子应用跑在localhost:3001主应用跑在localhost:8080它们之间是跨域的。qiankun会通过fetch拉取子应用的HTML再解析JS、CSS。如果子应用DevServer没有开启跨域头qiankun拉取失败你看到的跳转结果是“点击菜单没反应或者报错”。解决方式是子应用Webpack DevServer配置devServer: { port: 3001, headers: { Access-Control-Allow-Origin: * } }这个配置我基本在初始化脚手架时就会写好避免项目跑起来后遇到跳转问题还要中途插一脚。很多人会在这里卡很久因为在浏览器里直接访问子应用地址是正常的但在主应用壳子里就是加载不出来跳转自然也没效果。7. 跳转方案选型与封装建议7.1 中央跳转管理器的价值经历过这些坑之后我的做法是在主应用里封装一个“中央跳转管理器”所有应用之间的跳转都走这一条路。核心简化代码如下// 主应用里创建 navigationManager const navigationManager { goMain(path) { router.push(path) }, goApp(appName, path, query {}) { const targetPath /${appName}${path} router.push({ path: targetPath, query }) }, replaceMain(path) { router.replace(path) }, replaceApp(appName, path, query {}) { const targetPath /${appName}${path} router.replace({ path: targetPath, query }) } }在注册微应用时将navigationManager传入props。然后所有子应用内部只认这个manager对象不再直接操作window.location或history。好处非常明显跳转逻辑全部集中在一个地方后续如果要加埋点、鉴权、路由兜底只需要改主应用一处子应用开发人员不需要关心qiankun的实现细节直接调用props.navigationManager.goApp(user, /detail/123)就能跳转排查问题时思路清晰跳转出错先看主应用的manager实现再看具体传参7.2 路由守卫里处理统一的登录态与权限跨应用跳转时经常遇到一个问题应用A已经登录了但应用B还要再验证一次权限。如果每个应用各自校验体验很差。更合理的是在主应用路由守卫里统一校验登录态router.beforeEach((to, from, next) { const token localStorage.getItem(token) if (!token to.path ! /login) { next(/login) } else { next() } })子应用不再自行校验token而是在mount时从主应用的GlobalState里拿用户信息。这样子应用跳转时不会因为“尚未登录”被打断也很少出现跳转后又被踢回登录页的情况。这个设计虽然不属于“跳转方式”本身但却是跨应用跳转能否顺畅落地的关键前提。如果每个应用各自有独立的权限判断你从A跳B时就会被B的登录拦截挡住用户以为系统出错了。所以做跳转方案时权限模型也得一并考虑。7.3 何时不应该用qiankun的跳转而是用业务接口最后想说一个不是技术的坑不是所有“看起来像跳转”的操作都适合走前端路由。比如用户从订单微应用跳去用户微应用是想查看某个用户的详细档案这两个应用之间可能根本没有统一的会话状态。这时“跳转”其实应该先调用后端接口校验该用户在当前业务域是否有查看权限再决定放不放开页面。如果把权限校验放在前端跳转里做等于把重要的安全逻辑暴露给了攻击者。所以做好跨应用跳转不只是技术问题还是一个业务边界问题。先想清楚这次跳转是纯界面切换还是带权限校验的业务流转。两者对应的实现深度完全不同。8. 一个经验引以为戒先设计跳转规范再写业务我在多个微前端项目里吃过亏血的教训是跳转规范必须在项目起步时设计好不要等业务写了一半再回头补。因为一旦子应用各自为政有的用window.location.href有的用props跳转有的在GlobalState里监听跳转整个项目会变成一团乱麻。好的起步方式是文档里定义好四类跳转场景的API主应用实现navigationManager每个子应用的入口文件中统一挂载navigationManager各子应用代码里禁止直接改window.location和history这样做之后后面的业务开发基本不会踩跳转的大坑。就算踩了你也能通过navigationManager的统一日志快速定位问题而不是在多个子应用之间翻来翻去。qiankun作为微前端框架本身解决的是应用加载、隔离、通信跳转这块更多是“约定优于配置”。只要大家在业务代码里遵循统一的跳转规范把主应用当作中枢子应用之间的跳转就会像本地路由跳转一样自然。别让跳转成为微前端项目里最闹心的部分提前设计给团队省下大量排查时间这是我掏心窝子的建议。