技术负责人 | 微前端实践之Vue 3组合式

微前端实践之Vue 3组合式，我踏踏实实地搞过，也踩过不少坑。如果想用Vue 3实现微前端，得明白它不是简单的模块化，而是多应用协同。关键要在子应用之间共享状态、通信，还能保持各自独立。我用过qiankun，也试过微前端框架，但最难受的是子应用挂载时的生命周期问题，特别是子应用加载完成的判定。别看它简单，实际调试的时候，没少折腾。如果选了Vue 3组合式，得在setup函数里处理好挂载逻辑。我见过很多项目因为配置不当，子应用加载的时候出现白屏或者状态未初始化的bug。实际上，用qiankun做微前端，子应用入口必须是函数形式，不能是类，这点容易被忽略。而且，子应用引入的时候要注意全局变量污染，得用动态import，或者在main.js里用env变量判断是否加载。我试过用vite打包子应用，确实比webpack快很多，但配置上得多注意tree-shaking和模块热更新。 子应用的生命周期钩子是关键，比如mounted挂载完后，再执行一些逻辑。我之前有的项目在子应用初始化阶段没处理好，导致主应用先渲染，子应用还没准备好。这种情况下，得用qiankun的registerMicroApps方法，加上loading和activeOn的配置项，控制子应用加载的顺序和状态。如果子应用内部用的是Vue 3组合式API，记得在onBeforeMount和onMounted里面做额外处理，比如将全局的window对象注入到子应用的provide中。我见过一些子应用因为没有正确注入依赖，导致功能异常。而且，子应用的路由也要做特殊处理，不能直接用vue-router，得用qiankun的路由跳转方式，比如通过location.hash来控制。这样能保证主应用和子应用的路由不冲突，也不会出现404的问题。 vue3组合式在微前端中的使用，需要特别注意vite或webpack的打包配置。如果用vite，子应用打包的时候要把entry设置为一个函数，而不是一个组件，这样qiankun才能正确挂载。这部分配置容易忽略，但直接关系到能否顺利加载。子应用的index.html文件也要做调整，比如把base标签换成动态的，避免根路径冲突。我之前因为没改base，导致子应用在主应用里加载的时候，出现了404。另外，子应用的vuex模块也要独立，不能和主应用混在一起。可以考虑用命名空间隔离，或者通过provide/inject来传递状态。不过要注意，这样的方式会导致状态同步困难，特别是多子应用的情况下，容易产生数据不一致的问题。 跨应用通信是另一个大坑，我试过用postMessage，也见过用event bus的方式。postMessage在某些浏览器下会有延迟，或者被安全策略拦截，得在子应用里监听window.message事件，然后用event.origin来校验消息来源。而event bus的方式，容易造成内存泄露，特别是当子应用被卸载后，还没及时销毁event bus实例。我之前在子应用里用了一个全局的bus对象，结果多次加载卸载后，内存占用暴增，最后只能用vue3的provide/inject来替代。不过这种方式也不能完全解决跨应用通信的问题，还是得用qiankun的loadMicroApp方法，配合自定义的通信机制。比如用一个共享的store，或者用rabbitmq做消息中间件，但这样又增加了系统复杂度。 在实际部署中，子应用的缓存问题也很棘手。我见过某个子应用因为缓存问题，导致每次加载都使用旧版本，出现功能异常。解决办法是给子应用的入口文件加个随机哈希，这样每次打包都会生成新的文件名。还可以用vite的--mode参数来区分开发和生产环境，确保子应用不会加载错误的配置。另外，子应用的样式隔离问题也得注意，不能把主应用的样式带上。我用过scoped样式和CSS Modules，但发现有时候还是会污染主应用的样式。解决办法是用qiankun的样式隔离配置，设置sandbox的样式隔离模式。还有，子应用的依赖管理必须独立，不能和主应用共享，否则会引发版本冲突。我试过用npm包，还发现子应用的依赖树不清晰，导致打包体积过大。 技术背景与核心概念，必须明确微前端是什么。它不是单页应用的简单拆分，而是多个应用以某种方式组合在一起，形成一个完整的系统。Vue 3组合式API的引入，让开发更灵活，但也在微前端中增加了更多复杂度。比如，子应用的composable函数不能直接暴露给主应用，得通过自定义的通信机制来实现。主应用和子应用之间要共享状态，但又不能让状态变得混乱。这需要仔细设计状态管理方案，比如用一个全局store来保存共享状态，或者通过provide/inject传递。核心概念之一是子应用的挂载点，必须在主应用里通过一个容器来挂载，比如用，然后在qiankun里注册对应的应用。技术背景还包括前端架构演进，从单体到微服务，再到微前端，是应对复杂前端项目的一种解决方案。 具体操作方法或配置步骤，首先得确定技术栈。如果主应用是Vue 3，子应用也得是Vue 3。接下来是打包配置，用vite或webpack都要注意entry文件的写法。比如在vite的配置文件里，要设置entry为一个函数，而不是组件。然后是子应用的manifest配置，包括entry、activeWhen、loading等参数。这些参数是qiankun的注册必须项，不能漏掉。主应用里需要引入qiankun的库，然后通过registerMicroApps方法注册子应用。注册完成后，还要处理主应用的路由，确保子应用的路由不会和主应用冲突。比如用location.hash来匹配子应用的路由，或者在主应用的路由守卫里做特殊处理。另外，还要注意子应用的依赖注入，比如vue3的全局对象不能直接暴露给子应用，要通过自定义的provide/inject方式。 常见踩坑场景与避坑方案，子应用加载顺序就是个大问题。如果子应用之间有依赖关系，比如A应用需要B应用的数据，那必须保证A加载在B之后。否则会出现数据为空的情况。解决办法是在注册子应用的时候，用activeWhen参数指定触发的条件。比如，当主应用的路由是某个路径时，才加载子应用。另一个问题是样式隔离，如果子应用的CSS没有被正确隔离，会导致主应用的样式被覆盖。这时候得用qiankun的样式隔离配置，设置sandbox的样式隔离为true。还有，子应用的跨域问题，如果子应用部署在不同的域，就得在主应用里配置CORS，或者用代理服务器来解决。我之前遇到子应用加载失败，是因为没有正确设置CORS头，导致浏览器阻止请求。解决办法是在Nginx或Express服务器里添加相应的header配置。 性能影响或效率对比，Vue 3组合式在微前端中的表现，比vue2要好很多。它更轻量，响应更快，而且支持更灵活的状态管理。不过微前端本身会带来一些性能损耗，比如加载多个子应用时，会占用更多的内存和网络资源。我见过一个项目，因为加载了太多子应用，导致首屏加载时间变得很长。这时候得考虑优化子应用的打包体积，用vite的tree-shaking和code splitting来减少不必要的代码。另外，子应用之间的通信如果频繁，会影响整体性能。比如用postMessage来回传递消息，虽然能解决问题，但也会增加网络延迟。所以得尽量用共享状态或事件总线来替代。性能对比方面，vue3组合式在微前端中的表现，比react的微前端方案要稳定，但不如angular那样有成熟的微前端支持。 适用场景与局限性，适用于多团队协作的大型项目，每个子应用可以独立开发、测试、部署。这种模式能提升开发效率，降低耦合度。但局限性也很明显，比如子应用之间的通信复杂，需要额外的机制来处理。还有，微前端的调试也比单体应用难，因为多个应用混在一起，容易出现跨应用的错误。我之前就遇到过子应用的组件在主应用里调用失败，排查了好久才发现是子应用的依赖版本不一致。另外，子应用的样式隔离和全局状态管理，需要额外的配置，增加了开发成本。所以，如果项目规模不大，或者团队协作不成熟，可能不太适合用微前端方案。 替代方案或进阶技巧，除了qiankun，还有微前端框架如single-spa、Vue-SubApps等。不过qiankun在vue3中的支持更完善，用起来也更方便。进阶技巧包括用动态import来加载子应用，这样可以按需加载，提高性能。还有，用vite打包子应用时，可以配置--mode参数来区分开发和生产环境，避免打包错误。另外，子应用的生命周期钩子可以再细化，比如在onBeforeMount里做预加载，或者在onUnmount里清理资源。我见过有些子应用在卸载后，还会继续运行某些定时器，导致内存泄漏。所以得在onUnmount里显式地清除这些资源。还有，用webpack时，可以配置splitChunks来优化子应用的加载，减少冗余代码。 子应用的打包和部署，需要特别注意构建配置。比如在webpack的配置中，要设置publicPath为相对路径，这样子应用在不同环境下的加载才不会出错。我之前用过绝对路径，结果在某些部署环境下，子应用的资源加载失败。另外，子应用在部署的时候，要确保入口文件正确，不能有语法错误或者未定义的变量。如果子应用是用vite打包，还要注意生成的dist目录结构是否符合预期，否则qiankun加载的时候会报错。还有，子应用的静态资源要放在正确的路径下，比如放在子应用的根目录，而不是主应用的目录里。这是个容易被忽略的点，但影响很大。 子应用和主应用的通信，需要在子应用的入口文件里注入全局变量，这样主应用才能调用。比如在子应用的main.js里，用window对象来暴露某些方法，这样主应用可以通过window对象来调用子应用的功能。不过这种方法容易造成污染，得在子应用退出后，及时清理这些全局变量。我用过一个方案，在子应用的onUnmount钩子里，把window上的方法移除，这样就不会残留。另外，通信方式要尽量简单，比如用postMessage和监听事件的方式，而不是复杂的API调用。这样能减少跨应用的耦合，提高可维护性。 子应用的路由管理，必须和主应用保持独立。不能直接用vue-router，因为主应用的路由会和子应用冲突。我之前试过在主应用里用vue-router，然后在子应用里再注册自己的router，结果导致页面跳转混乱。解决办法是用qiankun提供的路由跳转方式，比如通过location.hash来匹配子应用的路由。这样能保证每个子应用的路由只在自己的上下文中生效。另外，子应用的路由还要注意权限控制，不能随便访问。比如用JWT认证，确保只有授权的用户才能访问对应的子应用。这需要在子应用的入口文件里，做权限判断，否则会出现安全漏洞。 子应用的依赖管理，必须独立。不能和主应用共用同一个依赖版本，否则会出现兼容性问题。我之前遇到一个子应用依赖了某个包的最新版本，而主应用用的是旧版本，结果导致功能异常。解决办法是在子应用的package.json里，单独指定依赖版本，这样打包的时候就不会冲突。或者在子应用里用npm install时，加上--save-dev参数，确保只在子应用内部使用。不过这种方式会导致依赖重复，增加包体积。所以得权衡利弊，看项目的需求。 子应用的生命周期钩子，要和主应用的钩子同步。比如在子应用的onMounted里，要确保主应用的某些资源已经加载完毕。我之前在子应用挂载后，直接调用主应用的某些方法，结果主应用还没初始化，导致错误。解决办法是在子应用的onBeforeMount里，先检查主应用是否已经准备好，再决定是否执行某些操作。或者用Promise来管理加载顺序，确保子应用的挂载是在主应用的某些操作完成后进行的。 子应用的样式和主题，要避免污染主应用。我用过scoped样式和CSS Modules，但发现有时候还是会混在一起。解决办法是在子应用的入口文件里，给样式添加一个唯一的类名，这样主应用的样式就不会影响到子应用。或者用qiankun的样式隔离配置，设置sandbox的样式隔离为true。这样能确保子应用的样式完全隔离，不会影响主应用的外观。不过这种方式可能会带来一些性能问题，比如样式重绘。得根据项目需求来决定是否启用。 子应用的热更新和调试，是另一个难点。我之前用vite做热更新，结果每次修改代码后，子应用的热更新不生效，导致调试困难。解决办法是在vite的配置里，开启hmr的自动刷新功能，或者在子应用的入口文件里，用import.meta.hot来处理热更新。这样能保证每次修改代码后，子应用能及时更新。不过热更新有时候会出问题，比如状态丢失，得在子应用的onUnmount钩子里，提前保存状态，再在onMounted里恢复。这样虽然麻烦，但能保证开发体验。 子应用的打包体积，是影响性能的重要因素。我试过用vite打包子应用，结果体积比webpack还大。这时候得优化代码，移除未使用的模块，或者用tree-shaking来减少冗余代码。还可以用代码分割，把子应用拆分成多个chunk，按需加载。不过代码分割需要谨慎，否则会导致代码加载顺序混乱。我遇到过一个子应用因为代码分割不当，导致某些模块无法加载，出现功能缺失的问题。所以得在打包配置里，仔细调整splitChunks和优化选项。 子应用的环境变量，也要注意管理。比如在子应用的.env文件里，不能直接使用主应用的环境变量，否则会引发错误。得在子应用的main.js里，通过window对象来获取主应用的环境信息。或者在子应用的入口文件里，用一个全局变量来存储环境配置，这样主应用就能动态传入。不过这种方式容易导致变量覆盖，得在子应用的初始化阶段，做变量校验。比如用process.env.NODE_ENV来判断当前环境，确保子应用的配置正确。 子应用的跨域问题，是部署时的常见问题。如果子应用部署在不同的域，得在主应用的服务器配置里，添加CORS头，比如Access-Control-Allow-Origin。否则浏览器会拦截请求。我之前在使用qiankun时，子应用的接口调用失败，是因为没配置CORS，导致403错误。解决办法是在Nginx或Apache里添加相应的header配置，或者在Express服务器里用cors中间件。不过跨域配置需要合理，否则会影响安全性。得根据项目需求来决定是否允许跨域访问。 子应用的动态加载和卸载，是微前端的核心能力之一。我用过qiankun的loadMicroApp方法来动态加载子应用，效果还不错。但卸载的时候，得确保子应用的资源被正确释放，比如清理定时器、移除事件监听器、销毁vue实例等。否则会导致内存泄漏，影响性能。我之前有过一个子应用因为没有清理资源，导致页面卡顿，最后只能手动在onUnmount钩子里做清理。不过这样会增加维护成本，得在代码中做到细致的管理。