我们常常听到后端同学津津乐道于“微服务”的解耦与敏捷，而前端似乎还常常被困在庞大的单体应用中动弹不得。你是否也曾面对一个历经数年维护、代码量惊人的巨石项目感到力不从心？每一次构建dou像是在等待一场漫长的日落，每一次修改dou牵一发而动全身。这时候，“微前端”的概念应运而生，而阿里开源的 Qiankun 框架，无疑是这片星空中Zui耀眼的一颗。今天我们就来聊聊这个让无数前端开发者既爱又恨的“乾坤”，到底藏着什么奥秘，又该如何驾驭它。

一、 破局：当单体应用成为累赘

想象一下你正在维护一个电商后台管理系统。起初，它只是一个简单的 Vue 项目，随着业务需求的疯狂增长，React 组件被硬塞进来Angular 的模块也被强行兼容，项目变得越来越臃肿。不同团队的代码在同一个仓库里“打架”，样式冲突成了家常便饭，甚至连发布上线dou成了一场。这就是典型的“单体前端”困境。

这时候，有人提出了“乾坤微服务”的构想。目标hen明确：将庞大的单体应用，拆解成多个可独立开发、独立部署、独立运行的小型应用，Zui后再像拼图一样无缝集成在一起。这听起来hen美好，但真的Neng落地吗？答案是肯定的，而且比你想象的要简单得多。

二、 乾坤初现：不仅仅是简单的拼凑

Qiankun 并不是凭空出现的魔法，它是基于 single-spa 的二次封装。Ru果说 single-spa 是一块精良的引擎，那么 Qiankun 就是装好了方向盘、减震器和舒适座椅的整车。它Zui大的优势在于开箱即用，尤其是对 HTML 入口的支持，让接入子应用变得异常丝滑。

hen多人会问：“后端讲微服务，前端讲微前端，没听过前端微服务啊？” 其实这只是一个称呼上的差异。在 Qiankun 的世界里我们geng习惯称之为“微应用”或“子应用”。它们本质上就是独立运行的 Web 应用，只是在被主应用“召唤”时才会乖乖地挂载到指定的容器中。

1. 主应用的“指挥棒”艺术

主应用，也就是我们常说的“基座”，它扮演着指挥家的角色。它负责调度所有的子应用，决定什么时候加载谁，什么时候卸载谁。在 Vue 的主应用中，我们通常会这样配置：

import { registerMicroApps, start } from 'qiankun';
// 我们Ke以定义一些需要传递给子应用的数据或方法
const props = {
  getMainData:  => store.state.globalState.mainData,
  updateMainData:  => {
    store.commit
  }
}
// 注册子应用
registerMicroApps();
// 启动乾坤
start({
  sandbox: {
    strictStyleIsolation: true, // 开启严格样式隔离，这hen重要！
    // experimentalStyleIsolation: true // Ru果遇到弹窗问题，Ke以尝试这个
  }
});

kan到这段代码，你可Neng会疑惑：entry 到底填什么？其实这就是子应用启动后的 HTTP 地址。Qiankun 会去抓取这个地址下的 HTML，解析出 JS 和 CSS，然后执行。这就像主应用去子应用的家里Zuo客，把它的家具dou搬过来放在自己的客厅里。

而在 App.vue 中，我们需要预留一个“客厅”：

2. 子应用的“独立宣言”

子应用在被主应用加载时需要表现出极高的配合度。它需要导出三个生命周期函数：bootstrapmount和 unmount。

以一个 Vue 子应用为例，我们需要改造它的 main.js

// 定义变量存储 Vue 实例
let instance = null
// 渲染函数
function render {
  const { container } = props
  // 乾坤会把容器传给你，避免挂载到主应用根节点
  instance = new Vue({
    router,
    store,
    render: h => h
  }).$mount : '#app')
}
// 独立运行时直接渲染
if  {
  render
}
export async function bootstrap {
  console.log
}
export async function mount {
  // props主应用传递的公共数据
  store.commit('SET_GLOBAL_STATE', {
    ...props,
    mainData: props?.getMainData || {}
  })
  render
}
export async function unmount {
  console.log
  instance.$destroy // 销毁实例
  instance.$el.innerHTML = '' // 清空 DOM
  instance = null
}

这里有一个非常关键的细节：container.querySelector。为什么主应用传递过来的 container Neng被识别？其实这是 Qiankun 内部通过 eject 机制或者约定俗成的规则实现的。主应用加载子应用时会将子应用的 HTML 内容解析并插入到 container 中，此时 container 内部就有了子应用的 DOM 结构，所以 querySelector 自然Neng找到。

三、 混合双打：Vue与React的共舞

乾坤Zui迷人的地方，莫过于它Neng轻松驾驭不同的技术栈。你Ke以在主应用是 Vue 3.0 的前提下无缝集成 Angular 和 React 子应用。这简直是技术选型自由度的福音！

对于 React 子应用，配置逻辑大同小异，但要注意 publicPath 的问题。Vue CLI 项目默认的 publicPath 是 '/'，这在子应用中可Neng会导致资源 404。Qiankun 虽然会自动修正部分静态资源路径，但为了保险起见，我们Zui好手动配置一下：

const { name } = require
module.exports = {
  webpack: {
    configure:  => {
      config.output.library = `${name}-`
      config.output.libraryTarget = 'umd' // 把微应用打包成 umd 格式
      config.output.chunkLoadingGlobal = `webpackJsonp_${name}`
      config.output.publicPath = process.env.NODE_ENV === 'development'
        ? 'http://localhost:3000/' 
        : '/'; // 方便引入静态资源不会404
      return config
    }
  },
  devServer:  => {
    config.headers = {
      'Access-Control-Allow-Origin': '*' // 允许跨域
    }
    return config
  }
}

这里不得不提一下 craco。Ru果你用的是 React 脚手架，不想 eject 暴露所有配置文件，那么 craco 就是一个完美的替代方案。它Neng让你在不破坏脚手架结构的前提下修改 Webpack 配置。

四、 沟通的艺术：数据如何在微应用间流转

微应用之间是隔离的，但这并不意味着它们要老死不相往来。在实际业务中，主应用和子应用、子应用和子应用之间往往需要共享数据，比如用户信息、Token 等。

1. 借道传书：Props 通信机制

这是Zui直观的方式。主应用在注册子应用时通过 props 传递数据和方法。子应用在 mount 生命周期中接收这些 props。

// 主应用
const props = {
  getMainData:  => store.state.globalState.mainData,
  updateMainData:  => {
    store.commit
  }
}
// 子应用
export async function mount {
  console.log
  // ...
}

2. 广播模式：GlobalState 的妙用

Ru果子应用之间需要通信，或者需要geng全局的状态管理，Qiankun 提供了 initGlobalState 方法。这就像建立了一个全局的广播站。

// qiankun/index.js
import { initGlobalState } from 'qiankun';
const initialState = {
  userInfo: {},
  token: ''
}
// 生成 actions
const actions = initGlobalState
// 监听全局变化
actions.onGlobalStateChange => {
  console.log
})
export { actions }

在组件中，我们Ke以通过 actions.setGlobalState 来geng新数据，所有订阅了该状态的子应用dou会收到通知。当然子应用之间通信通常还是需要主应用Zuo中转，毕竟“冤有头债有主”，数据流Zui好还是清晰一点。

五、 避坑指南：那些年我们踩过的坑

虽然 Qiankun hen强大，但在实际落地过程中，还是有不少让人抓狂的细节。这里分享几个常见的“坑点”，希望Neng帮你少走弯路。

1. 样式隔离的“结界”

开启 strictStyleIsolation: true 后Qiankun 会通过 Shadow DOM 来隔离样式。这虽然解决了样式冲突，但也带来了一些副作用，比如弹窗可Neng会被遮挡，或者一些依赖 document.body 插入节点的 UI 库会失效。这时候，你可Neng需要调整样式隔离策略，或者使用 experimentalStyleIsolation 作为折中方案。

2. 路由的“迷魂阵”

子应用的路由 base 设置至关重要。Vue Router 中，我们需要这样设置：

const router = new VueRouter({
  mode: 'history',
  base: window.__POWERED_BY_QIANKUN__ ? '/vue' : process.env.BASE_URL,
  routes
})

这里的 /vue 必须与主应用注册时的 activeRule 保持一致。否则，当你切换路由时子应用可Neng无法正确匹配，导致页面空白。React Router 也是同理，需要设置 basename。

3. 跨域与资源加载

在开发环境下子应用必须支持跨域。这是因为主应用是通过 fetch 请求去加载子应用的 HTML 和 JS 的。Ru果子应用的 DevServer 没有配置 Access-Control-Allow-Origin: *，浏览器就会毫不留情地拦截请求。

六、 ：拥抱变化，从乾坤开始

从 2018 年 Single-SPA 的诞生，到如今 Qiankun 的广泛应用，微前端架构Yi经逐渐成熟。它不是银弹，不Neng解决所有问题，但在面对大型项目重构、跨团队协作、遗留系统迁移等场景时它无疑是一把利器。

搭建一个基础的微服务框架并不难，难的是如何在后续的开发中保持架构的整洁，处理好各个微应用之间的边界。希望这篇文章Neng帮你解开对“乾坤微服务”的疑问。别被那些复杂的配置吓倒，动手试一试，你会发现，拆解巨石，其实并没有想象中那么可怕。毕竟海平面之上，冰山虽然只有八分之一，但水下的庞大支撑，才是我们技术人Zui坚实的底气。

---