这段代码的作用可以概括成一句话：

> **把 Spartacus 的 Mini Cart 功能注册成一个可按需加载的 Feature Module。只有当 Spartacus 真正需要 `MINI_CART_FEATURE` 时，才动态下载 `@spartacus/cart/base/components/mini-cart` 对应的 JavaScript chunk，并创建其中的 `MiniCartModule`。**

SAP 官方给出的 `CartBaseFeatureModule` 示例里，正是用这段配置来 lazy load Mini Cart。[SAP Help Portal](https://help.sap.com/docs/SAP_COMMERCE_COMPOSABLE_STOREFRONT/10a8bc7f635b4e3db6f6bb7880e58a7d/e047cd548b3f4c5ba08dbb5099f3c551.html?version=5.0\&utm_source=chatgpt.com)

把代码稍微整理一下：

```ts
provideConfig({
  featureModules: {
    [MINI_CART_FEATURE]: {
      module: () =>
        import('@spartacus/cart/base/components/mini-cart').then(
          (m) => m.MiniCartModule
        ),
    },
  },
});
```

可以从外向内一层层理解。

---

## 1. `provideConfig(...)` 在干什么

`provideConfig` 是 Spartacus 提供全局配置的一种方式。

它不是在这里直接执行 `MiniCartModule`，也不是等价于：

```ts
imports: [
  MiniCartModule
]
```

而是在告诉 Spartacus：

> `我这里注册了一段配置，请合并到 Spartacus 的全局 Config 中。`

SAP 官方把 `provideConfig` 描述为向 Spartacus 全局配置贡献一个 configuration chunk 的推荐方式之一。[SAP GitHub](https://sap.github.io/spartacus-docs/global-configuration-in-spartacus/?utm_source=chatgpt.com)

所以执行完：

```ts
provideConfig({
  featureModules: {
    ...
  }
})
```

之后，Spartacus 的全局配置里可以理解成多了一项：

```text
Config
└── featureModules
    └── miniCart
        └── module = 一个函数
```

注意这里存进去的是：

```ts
() => import(...)
```

这个**函数本身**。

此时并没有真正执行动态 `import()`。

这一点特别重要。

---

# 2. `featureModules` 是什么

```ts
featureModules: {
```

这是 Spartacus 自己定义的一套 **Feature Lazy Loading 注册表**。

可以把它想象成：

```ts
featureModules = {
  cart: {...},
  miniCart: {...},
  addToCart: {...},
  checkout: {...},
  organization: {...}
};
```

每一个 key 对应一个 Spartacus Feature。

官方文档说明，Spartacus 的 feature module lazy loading 可以实现：

- 不仅 lazy load UI component；
- 还可以 lazy load feature 的 core 逻辑；
- 第一次需要 feature 时才加载；
- 一个 feature 通常只初始化一次；
- 可以进一步声明 lazy dependency。[SAP Help Portal](https://help.sap.com/docs/SAP_COMMERCE_COMPOSABLE_STOREFRONT/eaef8c61b6d9477daf75bff9ac1b7eb4/6ae18e81bc8542b8885bb10bb046d5c8.html?utm_source=chatgpt.com)

所以：

```ts
featureModules
```

本质上就是告诉 Spartacus：

> `有哪些业务 Feature，以及当某个 Feature 第一次被需要时，应该怎样把它加载进来。`

---

# 3. `[MINI_CART_FEATURE]` 为什么有方括号

这一行：

```ts
[MINI_CART_FEATURE]: {
```

这里的 `[]` 是标准 JavaScript / TypeScript 的 **computed property name**，即计算属性名。

例如：

```ts
const MINI_CART_FEATURE = 'miniCart';
```

那么：

```ts
{
  [MINI_CART_FEATURE]: {
    ...
  }
}
```

运行之后就等价于：

```ts
{
  miniCart: {
    ...
  }
}
```

注意：

```ts
MINI_CART_FEATURE: {}
```

和：

```ts
[MINI_CART_FEATURE]: {}
```

不是同一件事。

前者创建的是字符串：

```text
MINI_CART_FEATURE
```

作为属性名。

后者会先计算变量：

```ts
MINI_CART_FEATURE
```

的值，再把这个值作为 key。

概念上：

```text
MINI_CART_FEATURE
        │
        ▼
     `miniCart`
        │
        ▼
featureModules[`miniCart`]
```

所以这一行是在注册：

> `MINI_CART_FEATURE 这个 feature 应该怎样加载。`

---

# 4. `module` 并不是 Angular Module 本身

接下来：

```ts
module: () =>
```

这个细节非常关键。

很多人第一次读会误以为：

```ts
module
```

里面保存的是：

```ts
MiniCartModule
```

其实不是。

它保存的是一个 **lazy loader function**：

```ts
() => Promise<MiniCartModule>
```

可以把它简化理解成：

```ts
const loadMiniCart = () => {
  return import('@spartacus/cart/base/components/mini-cart')
    .then((m) => m.MiniCartModule);
};
```

然后 Spartacus 保存：

```ts
featureModules['miniCart'].module = loadMiniCart;
```

所以在应用 bootstrap 时，仅仅发生：

```text
注册 loader
```

而没有发生：

```text
加载 MiniCartModule
```

---

# 5. 为什么这里一定要写成函数

关键就是这一层：

```ts
() =>
```

假如把它去掉，思路就完全变了。

现在：

```ts
module: () =>
  import(...)
```

意味着：

```text
先保存函数
   ↓
以后需要 Mini Cart
   ↓
才调用函数
   ↓
才执行 import()
```

也就是：

```text
Application startup
      │
      ├── 注册 lazy loader
      │
      └── 不加载 Mini Cart
              
              ...

CMS / Feature 第一次需要 Mini Cart
      │
      ▼
执行 module()
      │
      ▼
执行 import()
      │
      ▼
加载 JS chunk
```

这就是 lazy loading 的核心。

---

# 6. `import('@spartacus/cart/base/components/mini-cart')` 是真正的动态加载点

这一句：

```ts
import('@spartacus/cart/base/components/mini-cart')
```

不是普通的静态 ES Module import：

```ts
import { MiniCartModule }
  from '@spartacus/cart/base/components/mini-cart';
```

而是 **dynamic import**。

两者区别很大。

如果写：

```ts
import { MiniCartModule }
  from '@spartacus/cart/base/components/mini-cart';
```

构建工具看到的是：

```text
应用启动时就依赖 MiniCartModule
```

于是相关代码容易进入 eager dependency graph。

而：

```ts
import('@spartacus/cart/base/components/mini-cart')
```

意味着：

```text
这是一个异步依赖边界。
```

Angular/Webpack 构建时通常会把它拆成一个独立的 JavaScript chunk。

SAP 官方专门说明：

> 当 feature configuration 中通过 dynamic import 指向一个 feature module 时，构建过程会为该 feature 生成单独的 JavaScript chunk。[SAP GitHub](https://sap.github.io/spartacus-docs/lazy-loading-guide/?utm_source=chatgpt.com)

于是最终 bundle 结构可能类似：

```text
main.js
runtime.js
polyfills.js

chunk-xxxxx.js
    └── MiniCartModule
        ├── MiniCartComponent
        ├── dependencies
        └── providers
```

如果这个 session 从来没有需要 Mini Cart，那么这个 chunk 理论上就可以一直不加载。

---

# 7. 为什么 import 的路径这么长

这里：

```ts
@spartacus/cart/base/components/mini-cart
```

并不是随便选择的路径。

它体现了 Spartacus 非常重要的库设计原则：

> **为了让 tree shaking 和 lazy loading 真正有效，需要提供足够细粒度的 secondary entry point。**

SAP 官方明确提醒：

> 如果同一个 library entry point 同时被 static import 和 dynamic import，会破坏 lazy loading，并影响 tree shaking；因此适合动态加载的库应该暴露更细粒度的 entry points。[SAP GitHub](https://sap.github.io/spartacus-docs/lazy-loading-guide/?utm_source=chatgpt.com)

所以 Spartacus 并没有写：

```ts
import('@spartacus/cart')
```

或者：

```ts
import('@spartacus/cart/base')
```

来加载 Mini Cart UI。

而是进一步细分到：

```text
@spartacus/cart
      │
      └── base
            │
            └── components
                    │
                    └── mini-cart
```

这样可以尽量做到：

```text
Mini Cart 需要什么
        ↓
就加载什么
```

而不是：

```text
需要 Mini Cart
        ↓
整个 Cart library 全部加载
```

---

# 8. `import()` 返回的不是 `MiniCartModule`

这是理解这一行的另一个关键：

```ts
import('@spartacus/cart/base/components/mini-cart')
```

返回的是：

```ts
Promise<ModuleNamespace>
```

不是：

```ts
MiniCartModule
```

假设这个 entry point 导出了：

```ts
export class MiniCartModule {}

export class MiniCartComponent {}

export const MINI_CART_CONFIG = ...
```

那么：

```ts
import('@spartacus/cart/base/components/mini-cart')
```

resolve 以后得到的 `m`，概念上类似：

```ts
m = {
  MiniCartModule: ...,
  MiniCartComponent: ...,
  MINI_CART_CONFIG: ...
}
```

所以才需要下一步：

```ts
.then((m) => m.MiniCartModule)
```

---

# 9. `.then((m) => m.MiniCartModule)` 在干什么

这里：

```ts
.then(
  (m) => m.MiniCartModule
)
```

其实就是从动态 import 得到的 ES Module namespace 中，取出真正需要的：

```ts
MiniCartModule
```

因此整段：

```ts
() =>
  import('@spartacus/cart/base/components/mini-cart').then(
    (m) => m.MiniCartModule
  )
```

可以展开成：

```ts
function loadMiniCartModule() {

  const promise =
    import('@spartacus/cart/base/components/mini-cart');

  return promise.then((m) => {
    return m.MiniCartModule;
  });
}
```

整个类型关系可以理解为：

```text
module()
  │
  ▼
import(...)
  │
  ▼
Promise<ES Module Namespace>
  │
  ▼
.then(m => m.MiniCartModule)
  │
  ▼
Promise<MiniCartModule>
```

Spartacus 拿到这个结果后，就可以实例化对应 lazy feature。

---

# 10. 整段代码在应用启动时实际上发生了什么

这是最值得区分的地方。

应用启动：

```ts
provideConfig({
  featureModules: {
    [MINI_CART_FEATURE]: {
      module: () =>
        import(...).then(...)
    }
  }
});
```

这时候**不会立即执行**：

```ts
import('@spartacus/cart/base/components/mini-cart')
```

实际发生的更接近：

```text
Spartacus Configuration

featureModules
   │
   └── miniCart
          │
          └── module
                │
                └── function reference
```

因此：

```text
startup
  │
  ▼
把 loader 放进 config
  │
  X
  │
  └── 此时并没有下载 MiniCart chunk
```

---

# 11. 真正需要 Mini Cart 时才发生什么

假设当前 CMS page 中存在 Mini Cart 对应组件。

运行时逻辑可以抽象成：

```text
CMS page 被解析
      │
      ▼
Spartacus 发现需要 Mini Cart
      │
      ▼
找到 MINI_CART_FEATURE
      │
      ▼
读取：
featureModules[MINI_CART_FEATURE]
      │
      ▼
取得 module loader
      │
      ▼
调用 module()
      │
      ▼
执行 dynamic import()
      │
      ▼
浏览器请求对应 JS chunk
      │
      ▼
Promise resolve
      │
      ▼
m => m.MiniCartModule
      │
      ▼
取得 MiniCartModule
      │
      ▼
Angular 创建 / 初始化该 feature
      │
      ▼
Mini Cart 可以被渲染
```

SAP 官方对 feature module lazy loading 的描述正是：当 CMS 请求的 component 属于相应 feature 时，可以触发 feature module 的 lazy loading，并且 feature 第一次需要时才加载。[SAP Help Portal](https://help.sap.com/docs/SAP_COMMERCE_COMPOSABLE_STOREFRONT/eaef8c61b6d9477daf75bff9ac1b7eb4/6ae18e81bc8542b8885bb10bb046d5c8.html?utm_source=chatgpt.com)

---

# 12. 为什么 Mini Cart 要单独成为一个 Feature

你可能会自然产生一个问题：

> Mini Cart 明明属于 Cart，为什么不直接跟整个 Cart 一起加载？

这其实正体现了 Spartacus 的细粒度拆包思想。

SAP Commerce 5.0 之后对 cart library 做过明显拆分。官方把 base cart 的代码分为多个 entry point，例如：

```text
@spartacus/cart/base/assets
@spartacus/cart/base/components
@spartacus/cart/base/core
@spartacus/cart/base/occ
@spartacus/cart/base/root
@spartacus/cart/base/styles
```

而 Mini Cart 和 Add To Cart 又可以继续作为独立 lazy feature。[SAP Help Portal](https://help.sap.com/docs/SAP_COMMERCE_COMPOSABLE_STOREFRONT/10a8bc7f635b4e3db6f6bb7880e58a7d/e047cd548b3f4c5ba08dbb5099f3c551.html?version=5.0\&utm_source=chatgpt.com)

官方示例甚至同时注册三个 feature：

```ts
featureModules: {
  [CART_BASE_FEATURE]: {
    module: () =>
      import('@spartacus/cart/base').then(
        (m) => m.CartBaseModule
      ),
  },
}
```

以及：

```ts
featureModules: {
  [MINI_CART_FEATURE]: {
    module: () =>
      import('@spartacus/cart/base/components/mini-cart').then(
        (m) => m.MiniCartModule
      ),
  },
}
```

以及：

```ts
featureModules: {
  [ADD_TO_CART_FEATURE]: {
    module: () =>
      import('@spartacus/cart/base/components/add-to-cart').then(
        (m) => m.AddToCartModule
      ),
  },
}
```

这意味着 `Cart` 并不是：

```text
一个巨大模块
```

而是可以进一步拆成：

```text
Cart
│
├── Cart Base
│
├── Mini Cart
│
└── Add To Cart
```

用户只需要什么，就加载什么。[SAP Help Portal](https://help.sap.com/docs/SAP_COMMERCE_COMPOSABLE_STOREFRONT/10a8bc7f635b4e3db6f6bb7880e58a7d/e047cd548b3f4c5ba08dbb5099f3c551.html?version=5.0\&utm_source=chatgpt.com)

---

# 13. `CartBaseRootModule` 与这里的 lazy `MiniCartModule` 又是什么关系

官方完整的生成代码通常还有：

```ts
@NgModule({
  imports: [
    CartBaseRootModule
  ],
  providers: [
    provideConfig({
      featureModules: {
        [MINI_CART_FEATURE]: {
          module: () =>
            import(
              '@spartacus/cart/base/components/mini-cart'
            ).then(
              (m) => m.MiniCartModule
            ),
        },
      },
    }),
  ],
})
export class CartBaseFeatureModule {}
```

这里有一个非常值得注意的架构区别：

```text
CartBaseRootModule
```

是 eager 的。

而：

```text
MiniCartModule
```

是 lazy 的。

SAP 对这些 entry point 的约定是：

```text
/root
```

通常应该 eager load，里面放：

- config；
- events；
- facades；
- interceptors；
- models 等。

而更重的实际 feature implementation 可以 lazy load。官方 Cart Library Release Notes 就明确指出 `@spartacus/cart/base/root` 按约定是始终 eager loaded 的 entry point。[SAP Help Portal](https://help.sap.com/docs/SAP_COMMERCE_COMPOSABLE_STOREFRONT/10a8bc7f635b4e3db6f6bb7880e58a7d/e047cd548b3f4c5ba08dbb5099f3c551.html?version=5.0\&utm_source=chatgpt.com)

于是整体结构实际上是：

```text
Application startup
        │
        ▼
CartBaseRootModule
        │
        ├── Facade API
        ├── Config
        ├── Events
        └── Feature registration
                │
                │ 尚未加载
                ▼
          MiniCartModule
```

等真正需要 Mini Cart：

```text
MINI_CART_FEATURE
        │
        ▼
MiniCartModule
```

---

# 14. 最容易误解的一点：这里不是 `MiniCartComponent` lazy load

你上一问谈到了：

```ts
cmsComponents: {
  SomeComponent: {
    component: () => import(...)
  }
}
```

和当前代码非常像，但它们不是同一种粒度。

### CMS Component Lazy Load

例如：

```ts
cmsComponents: {
  SomeCMSComponent: {
    component: () =>
      import('./my.component').then(
        m => m.MyComponent
      )
  }
}
```

最终返回：

```text
Component class
```

---

### 当前这段 Feature Module Lazy Load

```ts
featureModules: {
  [MINI_CART_FEATURE]: {
    module: () =>
      import(...).then(
        m => m.MiniCartModule
      )
  }
}
```

最终返回的是：

```text
Angular Module
```

所以它不是简单：

```text
lazy load MiniCartComponent
```

而是：

```text
lazy load Mini Cart 这个 Feature 的 Angular Module
```

这个 module 内部可能包含：

```text
MiniCartModule
│
├── MiniCartComponent
├── directives
├── pipes
├── providers
├── config
└── 其他 dependency
```

因此它的 lazy loading 边界比单个 CMS Component 更大。

---

# 15. 结合你前面问的 SSR 问题，这段代码尤其值得注意

假设：

```text
CMS
  ↓
页面要求 MiniCart
```

于是 Spartacus 触发：

```ts
module()
```

实际执行：

```ts
import('@spartacus/cart/base/components/mini-cart')
```

这本质上还是一个：

```text
native dynamic import
```

也就是说这里会出现：

```text
dynamic import
      │
      ▼
Promise
      │
      ▼
异步加载 chunk
```

所以在 SSR 场景中，如果这个 feature 是当前 SSR HTML 所需要的，问题就转变成：

> Angular SSR 是否知道这里还有一个异步 feature/module 正在加载？

这和你之前分析的：

```ts
componentMapping.component()
```

非常相似。

区别只是：

```text
之前
CMS Component
    ↓
dynamic import(Component)
```

而这里：

```text
Feature
    ↓
dynamic import(Module)
```

二者底层都存在：

```text
import()
→ Promise
→ asynchronous module evaluation
```

所以从你目前研究的 SSR stability 角度，看到这种：

```ts
() => import(...)
```

就应该立即意识到：

> **这里存在一个异步 lazy-loading boundary。**

---

# 16. 可以把整段代码翻译成一句`人话`

原代码：

```ts
provideConfig({
  featureModules: {
    [MINI_CART_FEATURE]: {
      module: () =>
        import('@spartacus/cart/base/components/mini-cart').then(
          (m) => m.MiniCartModule
        ),
    },
  },
});
```

翻译成人话就是：

> `Spartacus，我现在注册一个叫 MINI_CART_FEATURE 的业务 Feature。应用启动时不要把 Mini Cart 的实现直接加载进来。当以后第一次真正需要这个 Feature 时，请动态加载 @spartacus/cart/base/components/mini-cart 这个代码包；加载成功以后，从这个包导出的内容中取出 MiniCartModule，并把它作为这个 Feature 的 Angular Module 进行初始化。`

整个生命周期就是：

```text
provideConfig()
       │
       ▼
注册 MINI_CART_FEATURE
       │
       ▼
保存 module loader function
       │
       │
       │   此时没有 import()
       │
       ▼
应用继续启动
       │
       ▼
某时刻需要 Mini Cart
       │
       ▼
调用 module()
       │
       ▼
import('@spartacus/cart/base/components/mini-cart')
       │
       ▼
请求 lazy JS chunk
       │
       ▼
Promise resolve
       │
       ▼
m.MiniCartModule
       │
       ▼
Angular 初始化 MiniCartModule
       │
       ▼
Mini Cart 功能可用
```

所以理解这段代码时，最关键的是区分三个阶段：

```text
provideConfig()
    =
注册加载规则

() => import(...)
    =
定义什么时候真正开始加载

.then(m => m.MiniCartModule)
    =
告诉 Spartacus 动态 package 加载完成后，
究竟取哪个 Angular Module
```

这三个阶段分清楚之后，Spartacus 的 `featureModules` lazy-loading 代码基本就完全透明了。[SAP Help Portal](https://help.sap.com/docs/SAP_COMMERCE_COMPOSABLE_STOREFRONT/eaef8c61b6d9477daf75bff9ac1b7eb4/6ae18e81bc8542b8885bb10bb046d5c8.html?utm_source=chatgpt.com)

把 Spartacus 的 Mini Cart 功能注册成一个可按需加载的 Feature Module。只有当 Spartacus 真正需要 MINI_CART_FEATURE 时，才动态下载 @spartacus/cart/base/components/mini-cart 对应的 JavaScript chunk，并创建其中的 MiniCartModule。

SAP Spartacus 的 lazy load feature Module

紫薇堂堂主

编程语言

开发工具

后端

使用provideConfig将MINI_CART_FEATURE注册为可延迟加载的FeatureModule，通过动态import()按需加载MiniCartModule。应用启动时仅保存加载函数，不执行代码下载；只有CMS页面真正需要MiniCart时才触发异步加载对应的JavaScript chunk，并初始化Angular模块，实现细粒度的性能优化。

代码解释

TypeScript 

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

使用provideConfig将MINI_CART_FEATURE注册为可延迟加载的FeatureModule，通过动态import()按需加载MiniCartModule。应用启动时仅保存加载函数，不执行代码下载；只有CMS页面真正需要MiniCart时才触发异步加载对应的JavaScript chunk，并初始化A...

SAP Spartacus 的 lazy load feature Module-腾讯云开发者社区-腾讯云

SAP Spartacus 的 lazy load feature Module

SAP Spartacus 的 lazy load feature Module

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐