single-spa工程化实践：从入门到精通

▌ 技术引导 single-spa 真正值钱的是它如何实现微前端架构的模块化与独立部署，同时保持单页应用（SPA）的性能优势。我见过很多项目因为没有正确配置路由或生命周期钩子导致子应用无法加载或出现闪屏，这直接关系到用户体验。如果你在做类似的事情，一定要记住：子应用的入口文件必须返回一个函数，该函数接受生命周期参数，比如 bootstrap、mount、unmount，并在 mount 时挂载到父应用的容器中。另外，子应用的路由必须和父应用完全隔离，避免出现路由冲突。我用过 webpack 的 splitChunks 配置来优化子应用的打包，这个配置对性能提升有明显帮助。别忘了子应用的预加载机制，提前加载资源可以减少首屏等待时间。 single-spa 的配置需要非常小心，尤其是子应用的路径和模块加载策略。我做过一个项目，因为子应用的 manifest 没有正确配置，导致多个子应用在同一个容器里重复加载，白白浪费了带宽和时间。正确的方式是使用 single-spa 的 registerApplication 方法，传入子应用的 name、loading component、active component、custom props，以及生命周期钩子的执行函数。动态加载子应用时，建议使用 fetch 或 axios 去获取子应用的 entry 文件，而不是直接引入。如果子应用依赖全局变量，可能需要用 window 或自定义的全局对象来传递，但要确保不会污染主应用的环境。还有，别忘了设置子应用的 env 变量，比如 VUE_APP_ENV，这样可以在不同环境里加载不同的子应用版本。 我见过很多团队在使用 single-spa 时，因为没有正确处理路由和子应用之间的交互，导致页面加载后无法正确显示内容。比如，子应用的路由是 /app1，但父应用的路由是 /app1，结果子应用的组件根本无法挂载。这时候得用 single-spa 的 routing 配置，把子应用的路由映射到不同的路径，或者用自定义的路由守卫来拦截。另外，子应用的样式隔离问题也容易被忽视，如果不配置 shadow DOM 或 CSS modules，可能会出现样式污染。我用过 loadable-components 来异步加载子应用的代码，这种方案比传统的 require 或 import 更加灵活，也更适合大规模微前端项目。 子应用的加载策略对整体性能影响很大。我做过一个案例，因为子应用一开始就加载了所有资源，导致首屏卡顿严重。后来改用动态加载，通过设置 webpack 的 splitChunks 和异步加载策略，把子应用分成多个 chunk，按需加载。这样首屏时间降低 30% 以上。同时，还要关注子应用的加载顺序和依赖关系。如果子应用 A 依赖子应用 B 的某个库，那么必须确保 B 先加载。否则会报错。在配置 single-spa 的生命周期钩子时，要确保每个阶段都能正确触发，比如 bootstrap 时执行初始化逻辑，mount 时渲染到容器，unmount 时卸载。这些细节如果不处理好，整个微前端架构就会变得不稳定。 真正的难点在于如何维护多个子应用的版本和依赖。我遇到过因为子应用版本不一致，导致多个依赖冲突的问题。这时候需要使用 yarn 或 npm 的 workspaces 功能，把所有子应用作为依赖项统一管理。另外，测试环境和生产环境的配置也需要差异化处理，比如在开发环境使用本地路径加载子应用，而在生产环境使用 CDN 或打包后的文件。如果子应用之间有共享的逻辑，可以创建一个公共模块，通过 import 的方式引入，但要确保这个模块在所有子应用中都能正确使用。这些经验都来自真实项目，不是理论上的建议。 ▌ 技术参考 single-spa 是一个用于构建微前端架构的框架。它的核心理念是将应用拆分成多个独立的子应用，每个子应用可以独立开发、测试、部署，但又能在同一个页面中运行。这种模式适合大型企业级应用，尤其是需要多个团队协作的项目。single-spa 的设计基于生命周期管理，每个子应用都要实现 bootstrap、mount、unmount 三个阶段的逻辑。这些生命周期钩子决定了子应用何时初始化、何时渲染、何时卸载。开发者需要根据这些钩子来编写代码，确保子应用在不同的状态和上下文中能正常运行。实际应用中，子应用的入口文件必须返回一个包含这些生命周期的函数，这样才能被 single-spa 正确识别和加载。 子应用的注册方式有两种：静态注册和动态注册。静态注册适用于子应用数量固定且已知的场景，通常在主应用的 entry 文件中调用 registerApplication 函数。例如： ```js registerApplication('app1', () => import('./sub-app1'), () => location.pathname.startsWith('/app1')); ``` 这段代码表示子应用 app1 在路径匹配 /app1 时被加载。动态注册则更适合子应用由外部管理的情况，比如通过配置文件或 API 动态加载。动态注册时，可以使用 registerApplication 的参数来传递子应用的配置，包括 name、loading component、active component 和自定义参数。这种方式在 CI/CD 环境中非常常见，因为它允许子应用的注册信息在部署时动态生成。需要注意的是，动态注册的子应用必须是 promise 的形式，否则会导致加载异常。 子应用加载时，如果路径冲突或者生命周期钩子未正确实现，可能会导致应用无法运行。比如，如果两个子应用的路由路径都匹配了 /app1，那么只有一个会被加载，而另一个会被忽略。这种情况下需要严格规划路由分隔策略，确保子应用的路径是唯一的。另外，子应用在 mount 时如果没有正确挂载到容器中，会导致页面空白或者组件未渲染。我见过一些项目因为忘记设置 container 元素，导致子应用无法显示。正确的做法是，主应用中定义一个 div 容器，然后在子应用的 mount 函数中，将该容器作为 DOM 插入点。例如，使用 document.getElementById('app1-container') 作为挂载点，确保子应用渲染到指定区域。 single-spa 提供了多种加载策略，包括静态加载、动态加载和异步加载。静态加载适用于子应用资源已经打包好的情况，直接使用 import 或 require 加载。动态加载则通过 fetch 或 axios 获取子应用的 entry 文件，再通过 eval 或 new Function 执行。异步加载通常结合 Loadable Components 或 Webpack 的 dynamic import 来实现，这种方式更适合大型子应用，能减少初始加载时间。在实际应用中，我倾向于使用异步加载，因为它能有效降低首屏时间。例如，使用 loadable-components 的 loadable 函数来包裹子应用的入口，代码如下： ```js import loadable from '@loadable/component'; const App1 = loadable(() => import('./sub-app1')); ``` 这种方式让子应用在需要时才加载，提升了整体性能。 子应用的生命周期钩子是 single-spa 最关键的部分之一。每个子应用都必须实现这三个钩子：bootstrap、mount 和 unmount。其中，bootstrap 用于初始化应用，mount 用于渲染应用到 DOM 容器，unmount 用于卸载应用。如果生命周期钩子未正确实现，子应用可能无法正确加载或卸载。例如，如果 bootstrap 阶段没有正确执行，子应用可能会在 mount 时找不到所需的依赖。另外，需要注意生命周期钩子的返回值，确保它们返回 Promise 或 boolean。如果返回值不正确，可能会导致 single-spa 的加载流程被中断。 子应用的样式隔离是 single-spa 架构中容易被忽视的问题。如果子应用的 CSS 没有正确隔离，可能会导致样式污染。解决这个问题的方法有多种，其中最常见的是使用 shadow DOM 或 CSS modules。shadow DOM 是一种浏览器原生的隔离机制，能有效防止子应用的样式影响主应用和其他子应用。例如，可以在子应用的入口文件中使用： ```js const root = document.createElement('div'); root.setAttribute('id', 'app1-container'); document.body.appendChild(root); ``` 然后通过 shadow DOM 将子应用的 UI 渲染到该容器中。CSS modules 则是通过编译的方式将类名转换为唯一标识，避免样式冲突。这两种方法各有优缺点，需要根据项目需求选择。我在实际项目中发现，shadow DOM 的实现较为复杂，尤其是在 Vue 或 React 中需要额外配置，而 CSS modules 则更简单，但需要对 CSS 代码进行打包处理。 子应用的路由配置对 single-spa 的运行至关重要。如果路由未正确隔离，可能导致多个子应用同时加载，或者子应用无法正确显示。通常的做法是使用 single-spa 的 routing 配置来限定子应用的加载路径。例如： ```js registerApplication('app1', () => import('./sub-app1'), () => location.pathname.startsWith('/app1')); ``` 这段代码确保只有当路径匹配时，子应用才会加载。如果多个子应用的路由路径相同，可能会导致加载冲突，需要仔细规划路由结构。另外，主应用的路由配置也需要考虑子应用的路由覆盖情况，避免出现 404 或 403 错误。在开发过程中，建议使用路由守卫来拦截请求，确保子应用的路由能正确映射到对应的组件。 子应用的依赖管理是 single-spa 架构中的另一个关键点。如果子应用依赖的库版本不一致，可能会导致兼容性问题。例如，主应用使用 Vue 2，而某个子应用使用 Vue 3，这会导致整个应用崩溃。为了解决这个问题，可以使用 yarn 或 npm 的 workspaces 功能，将所有子应用的依赖统一管理。此外，还可以使用 Webpack 的 externals 配置，避免重复打包第三方库。例如，在 Webpack 配置文件中添加： ```js externals: { vue: 'Vue', react: 'React', }, ``` 这样，子应用的依赖就会被直接使用主应用中的版本，而不是重新打包。这种方式可以减少打包体积，提高性能，但需要确保所有子应用都使用相同的依赖版本。 子应用的依赖注入方式也会影响 single-spa 的运行。默认情况下，子应用会从主应用中继承全局变量，如 window、document、localStorage 等。但有时候需要更细粒度的控制，比如将某些 API 路由或样式配置暴露给子应用。这时候可以使用 single-spa 的 customProps 配置，将需要的变量传递给子应用。例如： ```js registerApplication('app1', () => import('./sub-app1'), () => location.pathname.startsWith('/app1'), { api: 'https://api.example.com/v1', auth: 'Bearer token' }); ``` 这段代码在子应用的生命周期钩子中，通过 props 参数获取到 api 和 auth，这在开发登录、支付等功能时非常有用。不过，需要注意 props 的传递方式，避免因为配置错误导致子应用无法获取必要的信息。 子应用的打包策略也需要根据项目规模和性能需求进行调整。对于小型项目，可以使用 Webpack 的 splitChunks 配置将子应用的代码拆分成多个 chunk，按需加载。例如，在 Webpack 配置文件中添加： ```js optimization: { splitChunks: { chunks: 'all', minSize: 10000, maxSize: 250000, minChunks: 1, maxAsyncRequests: 30, maxInitialRequests: 10, name: true, cacheGroups: { vendors: { test: /[\\/]node_modules[\\/]/, name: 'vendors', chunks: 'all' } } } } ``` 这段配置将子应用的代码和第三方库分开打包，提高了加载效率。对于大型项目，建议使用 Webpack 5 的 magic comment 来指定子应用的 chunk，例如： ```js import('./sub-app1').then(module => module.default); ``` 这种方式能更精细地控制子应用的加载，确保资源按需加载。 子应用的加载顺序对用户体验有直接影响。如果多个子应用同时加载，可能导致资源浪费和页面卡顿。因此，在 registerApplication 时，应该根据子应用的优先级和依赖关系来决定加载顺序。例如，可以将核心子应用放在前面，确保它们优先加载，而次要子应用可以稍后加载。此外，还可以使用 Webpack 的 splitChunks 配置来优化加载顺序，将常用于多个子应用的公共代码提取出来，减少重复加载。如果子应用之间有依赖关系，必须确保依赖项先加载，否则会出现依赖缺失的问题。 子应用的性能优化是 single-spa 架构中的重要环节。除了使用 splitChunks 和 dynamic import，还可以通过懒加载和缓存策略进一步提升性能。懒加载可以让子应用在需要时才加载，而不是一开始就加载所有资源。例如，使用 Webpack 的 lazy loading 功能： ```js const App1 = () => import('./sub-app1'); ``` 这种方式结合 single-spa 的 lifeCycle 配置，可以实现按需加载。缓存策略则可以通过 HTTP 缓存头或 service worker 来实现，减少子应用的加载时间。例如，在 Nginx 配置中添加： ```nginx location /sub-app1 { add_header Cache-Control "public, max-age=31536000"; } ``` 这样，子应用的资源可以被浏览器缓存，提升后续访问速度。另外，还可以使用 Webpack 的 SplitChunks 配置，将子应用的代码拆分成多个块，按需加载，避免一次性加载过多资源。 子应用的错误处理是 single-spa 架构中容易被忽视的部分。如果子应用加载失败，整个页面可能会崩溃，导致用户体验下降。因此，在 registerApplication 时，需要添加错误处理逻辑。例如，使用 try-catch 来捕获加载错误： ```js registerApplication('app1', () => { try { return import('./sub-app1'); } catch (error) { console.error('Sub-app1 failed to load:', error); return Promise.reject(error); } }, ...); ``` 这种方式可以确保子应用加载失败时不会影响主应用的运行。另外，还可以使用 Webpack 的 onerror 配置来监听加载错误，例如： ```js module.exports = { onerror: (err, source, chunkName, originalChunkName, async) => { console.error('Webpack error:', err); } }; ``` 这段配置能帮助开发者及时发现子应用加载过程中的错误，提高调试效率。 子应用的版本控制和热更新是 single-spa 架构中的难点。如果子应用的版本没有统一管理，可能会导致不同版本的子应用同时运行，造成兼容性问题。因此，建议在子应用的配置文件中明确版本号，并在加载时根据版本号选择对应的子应用。例如，在子应用的 manifest 文件中添加版本字段： ```json { "name": "app1", "version": "1.0.0" } ``` 然后在主应用中根据版本号动态加载子应用。此外，热更新可以通过 Webpack DevServer 实现，确保子应用在开发过程中能及时更新。例如，在开发环境使用： ```js webpackDevServer: { hot: true, publicPath: '/dist/' } ``` 这样，当子应用的代码发生变化时，浏览器会自动更新，提高开发效率。不过，热更新可能会导致子应用的重新加载，因此需要在配置中设置合适的策略。 子应用的容器管理对 single-spa 的运行稳定性至关重要。容器的大小、位置和样式会影响子应用的显示效果。因此，在注册子应用时，主应用需要确保容器元素已经存在，并且大小合适。例如，在 HTML 文件中预定义一个容器： ```html ``` 然后在子应用的 mount 函数中，将该容器作为挂载点。如果容器不存在，子应用可能无法正确渲染，导致页面空白。此外，容器的样式需要与主应用的布局兼容，避免子应用的 UI 与主应用的布局冲突。在实际项目中，我见过因为容器样式设置不当，导致子应用的 UI 被压缩或拉伸，影响用户体验。因此，需要在容器的 CSS 中设置合适的宽高、位置和背景色。 子应用的依赖隔离是 single-spa 架构中的另一个关键问题。如果子应用依赖的库与主应用冲突，可能会导致功能异常。例如，主应用使用 Vue 2，而子应用使用 Vue 3，这会导致整个应用崩溃。为了解决这个问题，可以使用 Webpack 的 externals 配置，确保子应用使用主应用的依赖版本。例如，在 Webpack 配置文件中添加： ```js externals: { vue: 'Vue', react: 'React' } ``` 这样，子应用的依赖会被直接使用主应用中的版本，而不是重新打包。此外，还可以使用 yarn 或 npm 的 workspaces 功能，统一管理所有子应用的依赖版本，确保一致性。如果子应用需要独立的依赖版本，可以使用 Webpack 的 splitChunks 配置，将不同版本的依赖打包成不同的 chunk，避免冲突。