企业官网建设流程全解析

1. 项目概述与整体设计思路

我的结论是：乾坤（Qiankun）没有提供官方现成的“父子应用全自动状态同步面板”，所以如果你的项目需要主应用把用户信息、权限、主题配置一股脑塞给子应用，同时还想让子应用反过来通知主应用刷新数据，最务实的路线就是把“生命周期”和“数据通信”这两件事先彻底吃透。本文要聊的实战内容，正是围绕这个核心诉求展开。

1.1 微前端里的生命周期到底指什么

很多同学第一次接触乾坤，看到“生命周期”三个字就以为只是子应用暴露出来的bootstrap、mount、unmount三个函数。这个理解不够完整。乾坤的生命周期其实分成两个层面：子应用自身暴露的生命周期和主应用注册时使用的全局生命周期钩子。

子应用自身暴露的三个生命周期，是乾坤框架要求每个子应用必须对外提供的基本函数：

• bootstrap：子应用首次启动时执行，相当于“初始化”，适合做一些只在首次加载时需要做的事，比如创建全局单例、初始化公共资源。
• mount：每次子应用被激活时执行，是真正渲染页面、挂载 DOM 的地方，也是在路由切入后恢复应用状态的关键位置。
• unmount：子应用被切走时执行，负责清理 DOM、解除事件监听、销毁实例，避免内存泄漏和样式/事件污染。

全局生命周期钩子则是主应用在注册子应用时传入的一组函数，用来监听整个微前端的加载过程。这组能力常被忽略，但它非常有用。

1.2 为什么把数据通信和生命周期放在一起实践

原因很简单：很多实际业务中的通信动作，必须依赖生命周期时机才能做对。

举个例子，主应用登录后拿到了用户 token，需要下发给子应用 A。如果子应用 A 还没有mount，直接发数据就会丢失；如果子应用已经mount完成，你还需要确保它已经注册好了“接收数据”的事件监听，数据才不会漏接。所以你看，生命周期编排和数据通信从来不是独立的两个话题，它们是同一套工程实践中的上下半场。

另外，不少团队在评估微前端时，最担心的就是“子系统之间数据怎么同步”“主应用状态变了,子应用能不能感知”。这类担忧背后真正的技术问题，其实就是“通信方案如何选择”以及“消息如何对齐生命周期”。把这两个问题解决了，微前端的核心地基就打牢了。

1.3 适用场景与读者画像

这篇文章适合的区域很明确：你已经了解乾坤的基本用法，能跑通一个简单的 Demo，但不确定在实际业务里怎么优雅地传数据；或者你的项目规模变大后，发现各个子应用的状态管理有些混乱，想找一套可以复制到生产环境的规范方案。

我会以“主应用 + 两个子应用”的完整工程为主线，把生命周期机制、三种数据通信方式、选型建议、排查技巧全部串起来，争取你看完就能在自己的项目里直接套用。

2. 生命周期机制拆解与钩子执行时机

提示：理解乾坤生命周期的核心口诀是“加载时初始化，激活时挂载，切走时销毁”。这句口诀可以在后续排查问题的时候快速帮你定位“当前状态到底卡在哪一步”。

2.1 子应用三个必要生命周期函数的实现细节

每个乾坤子应用需要在自己的入口文件（通常是main.js或index.js）里导出三个生命周期函数。下面是一段最基础、也最推荐的模板：

// 子应用入口文件 let root = null; export async function bootstrap() { // 这里只做一次性初始化 console.log('子应用 bootstrap 执行'); } export async function mount(props) { // props 里包含主应用传入的数据、路由信息等 console.log('子应用 mount 执行，收到 props：', props); root = renderRoot(props); } export async function unmount() { // 切换离开时，清理 DOM 和副作用 console.log('子应用 unmount 执行'); if (root) { root.$destroy?.(); root = null; } }

这里有两个容易被忽略的细节。

第一，mount可能会被多次触发，所以里面不能只做“初始化”而忘了处理重复渲染。如果子应用是 Vue，请确保root变量是可重入的；如果子应用是 React，需要考虑ReactDOM.createRoot和root.render的调用方式，避免重复创建根节点。

第二，unmount里的清理动作一定要彻底。在实际项目中，我遇到过因为unmount没有移除全局window.addEventListener导致页面卡顿、路由切换后事件重复触发的线上事故。处理原则是：凡是 mount 里注册的，unmount 里都要找到并注销。

2.2 主应用级别的生命周期钩子编程

乾坤在主应用注册子应用时，允许通过lifeCycles参数配置全局钩子，它会在子应用各个阶段自动回调。代码示例如下：

import { registerMicroApps, start } from 'qiankun'; registerMicroApps( [ { name: 'app-vue', entry: '//localhost:8081', container: '#subapp-container', activeRule: '/app-vue', }, { name: 'app-react', entry: '//localhost:8082', container: '#subapp-container', activeRule: '/app-react', }, ], { beforeLoad: [ async (app) => { console.log('beforeLoad', app.name); // 可在子应用加载前做统一处理，比如显示全局 Loading }, ], beforeMount: [ async (app) => { console.log('beforeMount', app.name); }, ], afterMount: [ async (app) => { console.log('afterMount', app.name); }, ], beforeUnmount: [ async (app) => { console.log('beforeUnmount', app.name); }, ], afterUnmount: [ async (app) => { console.log('afterUnmount', app.name); }, ], } ); start();

这套全局钩子的价值在于：你不需要在每个子应用里重复写“上报当前状态”“切换 loading 状态”之类的逻辑，主应用可以在特定时机统一处理。

2.3 生命周期设计中三个常见的坑

第一个坑：子应用渲染时机与主应用传参时机错位。如果主应用通过全局状态库发数据，但子应用还没mount，那么状态变化事件可能被错过。解决方法是子应用在mount里主动读一次“最新状态”，而不是只依赖事件推送。

第二个坑：子应用切换过快导致unmount与mount竞争。快速切换菜单时，前一个子应用的卸载还没完成，后一个子应用就开始挂载，随之而来的是 DOM 渲染混乱。推荐做法是在主应用路由切换处加一层“锁”，确保afterUnmount后再允许下一个子应用mount。

第三个坑：在bootstrap里访问 DOM 或依赖存在 DOM 环境下的库。bootstrap阶段子应用可能还没有插入 DOM 容器，一切涉及document的操作都应该推迟到mount中。

3. 数据通信方案拆解，从 Props 到全局状态

乾坤的通信方式，从官方能力到业务实践，基本可以分成三类：基于 Props 的下发模式、基于全局状态的订阅发布模式、基于自定义事件的解耦模式。三者没有绝对优劣，只有“在这个场景下合不合适”。

3.1 Props 下发：适合主应用向子应用传递初始化快照

Props 是乾坤在mount时自动传给子应用的一组数据，它天然适合“一次性下发基础信息”。典型场景包括：用户 ID、角色权限列表、当前主题、菜单配置等。主应用侧代码如下：

registerMicroApps([ { name: 'app-vue', entry: '//localhost:8081', container: '#subapp-container', activeRule: '/app-vue', props: { userInfo: { id: 1, name: '张三' }, permissions: ['admin', 'editor'], theme: 'dark', }, }, ]);

子应用侧接收：

export async function mount(props) { const { userInfo, permissions, theme } = props; // 使用这些初始化数据渲染应用 }

这里要特别提醒：Props 不是响应式的。如果主应用在子应用已经mount之后修改了props里的某个对象，子应用不会自动感知。指望 Props 做“实时同步”是不现实的，它只适合做“快照式下发”。

3.2 全局状态：官方推荐的订阅发布模式

乾坤提供了initGlobalState、onGlobalStateChange、setGlobalState这一组 API，用于在主应用与子应用之间建立响应式的数据通道。

主应用侧初始化全局状态：

import { initGlobalState } from 'qiankun'; // 定义全局状态 const actions = initGlobalState({ userInfo: { id: 1, name: '张三' }, theme: 'light', unreadCount: 0, }); // 主应用监听全局状态变化 actions.onGlobalStateChange((state, prev) => { console.log('主应用监听状态变化：', state, prev); }); // 主应用修改全局状态 actions.setGlobalState({ unreadCount: 10, });

子应用侧接收和修改：

let globalActions = null; export async function mount(props) { // props 上自带 onGlobalStateChange 和 setGlobalState const { onGlobalStateChange, setGlobalState } = props; // 注册监听函数 onGlobalStateChange((state, prev) => { console.log('子应用感知到状态变化：', state, prev); // 更新自己的页面数据 }); // 需要时可反向修改全局状态 setGlobalState({ unreadCount: 100, }); }

这套方案的优点很明显：数据是打通的，任意一端修改全局状态，另一端都会收到通知。需要注意的是，避免在onGlobalStateChange的回调里继续调用setGlobalState修改同一个字段，否则容易形成循环更新，导致应用崩溃或性能下降。

3.3 自定义事件：跨子应用通信的轻量方案

如果两个子应用之间需要直接通信，或者你不想把状态全部挂到全局 store 里，可以采取浏览器的CustomEvent来自己做一套事件总线。这个方向的优点是灵活、完全不依赖乾坤 API，缺点是事件名容易重名、调试成本高、出错时不容易发现。

下面是一个精简实现，可以在主应用或子应用里直接使用：

// 发送事件 window.dispatchEvent( new CustomEvent('order:updated', { detail: { orderId: 123, status: 'paid' }, }) ); // 接收事件 window.addEventListener('order:updated', (event) => { const { orderId, status } = event.detail; console.log(`订单 ${orderId} 状态更新为 ${status}`); });

需要注意，监听事件的代码要在子应用mount期间注册，并在unmount时移除，否则缓存或切换重建后会出现重复监听。

3.4 三种通信方式怎么选

我的实践经验是：能用 Props 的用 Props，需要实时同步的用全局状态，局部业务事件用自定义事件。不要一上来就把所有数据都塞进全局状态里，否则后期会陷入“全局状态乱成一团”的泥潭。

4. 实战演练：主应用 + 两个子应用的完整工程

这一部分，我带大家从头搭建一个可以直接运行的 Demo。工程使用 Vite 作为主应用构建工具，子应用分别采用 Vue 3 和 React 18。整个过程会体现生命周期钩子的联动和数据通信的三种用法。

4.1 工程结构划分

建议在根目录下建三个独立项目，方便独立开发和部署：

qiankun-demo/ ├── main-app/ # 主应用（Vite + Vue 3） ├── sub-app-vue/ # 子应用 Vue（Vite） ├── sub-app-react/ # 子应用 React（Webpack 5 或 Vite 插件）

每个子应用都是完整的可独立运行工程，主应用通过乾坤在运行时加载它们。独立运行子应用时，你可以像开发普通单页应用一样开发调试。

4.2 主应用注册与生命周期联动

主应用入口文件main.js中注册两个子应用，并挂载全局生命周期钩子。这里我会做成一个“加载状态管理器”，统一处理子应用切换过程中的 UI 反馈。

import { registerMicroApps, start, initGlobalState } from 'qiankun'; const actions = initGlobalState({ userInfo: null, theme: 'light' }); function setLoading(show) { document.getElementById('global-loading').style.display = show ? 'block' : 'none'; } registerMicroApps( [ { name: 'sub-vue', entry: '//localhost:8081', container: '#subapp-viewport', activeRule: '/sub/vue', props: { moduleCode: 'vue-module', }, }, { name: 'sub-react', entry: '//localhost:8082', container: '#subapp-viewport', activeRule: '/sub/react', props: { moduleCode: 'react-module', }, }, ], { beforeLoad: [ async () => { setLoading(true); }, ], beforeMount: [ async () => { console.log('子应用即将挂载'); }, ], afterMount: [ async () => { setLoading(false); console.log('子应用已挂载完成'); }, ], beforeUnmount: [ async () => { setLoading(true); }, ], afterUnmount: [ async () => { setLoading(false); }, ], } ); actions.onGlobalStateChange((state) => { console.log('全局状态变化：', state); }); start();

4.3 子应用暴露生命周期

Vue 子应用入口改造如下，关键在于导出三个生命周期函数，并且mount时接收乾坤传入的 Props。

// sub-app-vue/src/main.js import { createApp } from 'vue'; import App from './App.vue'; import { createRouter, createWebHistory } from 'vue-router'; let app = null; let router = null; export async function bootstrap() { console.log('Vue 子应用 bootstrap'); } export async function mount(props) { console.log('Vue 子应用收到 props：', props); router = createRouter({ history: createWebHistory('/sub/vue'), routes: [], }); app = createApp(App); app.use(router); app.mount(props.container); } export async function unmount() { console.log('Vue 子应用 unmount'); app?.unmount(); app = null; }

React 子应用入口改造类似，需要注意createRoot的挪用与清理。

// sub-app-react/src/index.js import React from 'react'; import { createRoot } from 'react-dom/client'; let root = null; export async function bootstrap() { console.log('React 子应用 bootstrap'); } export async function mount(props) { console.log('React 子应用收到 props：', props); root = createRoot(props.container); root.render(<App />); } export async function unmount() { console.log('React 子应用 unmount'); root?.unmount(); root = null; }

4.4 数据流打通完整示例

现在，把用户信息放进全局状态，然后让两个子应用都订阅这份数据。同时，子应用内部也可以修改全局状态。

主应用侧：

actions.setGlobalState({ userInfo: { id: 1001, name: '张三' }, });

Vue 子应用侧：

export async function mount(props) { const { onGlobalStateChange, setGlobalState } = props; onGlobalStateChange((state) => { // 收到最新用户信息后，更新页面显示 if (state.userInfo) { localStorage.setItem('userInfo', JSON.stringify(state.userInfo)); } }); }

React 子应用侧：

export async function mount(props) { const { onGlobalStateChange, setGlobalState } = props; onGlobalStateChange((state) => { if (state.userInfo) { // 更新 React 组件状态 } }); }

这样，主应用登录后只需要调一次setGlobalState，两个子应用都会感知到用户信息变化并更新界面，真正做到“一次下发，多点生效”。

5. 常见问题与排查手记

5.1 子应用 mount 后页面空白

页面空白十有八九是container选择器写错了，或者容器没有被正确渲染。排查时先打印props.container，确认它是一个存在的 DOM 节点。如果使用 Vue，mount可以接收 DOM 节点，也可以接收选择器字符串；但 React 的createRoot必须接收 DOM 节点。

另一个常见原因是子应用路由基路径没配置正确。比如主应用通过/sub/vue激活子应用，但子应用内部的路由没有设置base: '/sub/vue'，导致子应用内部路由匹配失败，页面自然渲染不出来。

5.2 全局状态更新后，子应用没有刷新

优先级最高的检查项：子应用是否真的注册了onGlobalStateChange。如果监听注册得太晚，或者注册代码被放在异步组件里，就可能错过触发时机。解决办法是：在mount里**【先注册监听，再读取一次当前状态】**。这样即使状态在子应用挂载前已经变化过，挂载后也能立刻拿到最新值。

另外一个隐蔽原因是：子应用内部用了“状态副本”，比如把全局状态缓存到了自己的 Vuex 或 Redux store 里，而全局状态变化只是写到了 localStorage，没有同步到本地 store。这种情况下，监听回调里要把数据真正推入子应用的本地状态管理，界面才会刷新。

5.3 页面切换后，旧子应用的定时器还在跑

这是典型的unmount清理不彻底问题。排查手册建议分三步走：

1. 在unmount里检查是否清除了所有setInterval、setTimeout。
2. 在unmount里检查是否移除了全局window.addEventListener。
3. 在unmount里检查是否销毁了组件实例、Router 实例、状态管理实例。

如果组件内部用了第三方库（如 ECharts、Monaco Editor），还需要额外调用对应的dispose或destroy方法。

我在实际项目里就是吃了这个亏：某个子应用里有一个 WebSocket 长连接，只在mount时建立，却在unmount时忘了断开，结果切走之后连接依然存活，白白消耗服务器资源，还导致重复消息推送。后来规范统一在unmount阶段做“清理三连”，问题才彻底消失。

5.4 子应用之间样式互相污染

样式污染虽然在严格分类里不算生命周期问题，但频繁在切换时暴露。原因是子应用卸载后，动态插入的style标签可能没有被完整移除。排查手段包括：

• 子应用内样式尽量加 scoped 或 css module。
• 使用乾坤提供的sandbox能力，但不要盲目依赖。
• 如果发现样式残留，可以在unmount里手动移除子应用注入的style标签。

5.5 快速切换菜单导致子应用加载异常

快速连续点击菜单，最常见的结果是子应用加载超时或子应用 mount 未完成。这不是乾坤的 bug，而是 JS 加载时机、路由切换时机和mount完成时机三者不匹配导致的。

一个比较实用的处理方式：在主应用的beforeLoad里设置一个“加载锁”标志，在afterMount或afterUnmount里释放锁；当锁未释放时，后续的切换请求排队等待。虽然看上去会损失一点路由切换的“爽快感”，但能换来整体稳定性，生产环境值得这么干。

6. 生命周期与数据通信配合的实践心得

如果把手头的项目比作一台机器，生命周期就像是“机器的启动、暂停、停止按钮”，数据通信就像是“按钮之间连续运转的传动轴”。两者配合好了，整个微前端架构才会运转流畅。

我个人在多次实战后沉淀出一套非常管用的经验：

1. 子应用单独运行时，也要保证能跑通。确保子应用业务逻辑不依赖“乾坤环境”，一旦挂载到主应用出现问题时，你可以在子应用独立环境里排查，避免“混在一起查半天”。
2. 数据下发时，主应用先保证“子应用已就绪”。这里的“就绪”不是简单地子应用mount完成，而是子应用内部的监听器已注册完成。
3. 所有全局状态字段要集中定义。建议在主应用建立一个global-state.config.js，把状态字段名、类型、默认值统一管理，避免子应用各自起名的乱象。
4. 及时在卸载时清理一切。不只是框架实例，还包括公共事件、定时器、全局监听、子应用创建的样式元素等，宁可过度清理也不要留下隐患。

这套小结不是教科书理论，而是我在线上项目里用过好几轮的真实心得。乾坤把一个复杂微前端架构的“基础设施”做得很顺手，但真正的掌控力，还是掌握在开发者对生命周期和数据通信的理解深度上。只要这两个核心点稳住了，后续接入多少个新子应用，整体架构都不会慌。