SAP Spartacus 同时提供 **CMS Component Lazy Load** 和 **Feature Module Lazy Load**，背后的核心意图其实是一致的：

> **不要让整个 Storefront 的所有 JavaScript、业务逻辑、NgRx 状态和组件在应用第一次启动时全部进入 main bundle，而是根据 CMS 当前真正需要的内容，按需加载对应代码。**

但两者解决问题的粒度不同。可以把它理解成：

- **CMS Component Lazy Load：按`一个组件`拆代码**
- **Feature Module Lazy Load：按`一个完整业务功能`拆代码**

这也是 Spartacus 相比普通 Angular 应用比较特殊的地方。

SAP 官方明确解释：普通 Angular lazy loading 往往是 **route-based code splitting**，但 Spartacus 是高度 **CMS-driven** 的。构建时并不能完全知道 `/`、`/product/...`、`/category/...` 最终会由哪些 CMS Components 组成，因为业务人员以后可以通过 CMS 修改页面结构。因此 Spartacus 需要一套由 CMS 运行时需求触发的 lazy loading 机制。[SAP GitHub](https://sap.github.io/spartacus-docs/lazy-loading-guide/?utm_source=chatgpt.com)

---

## 1. 为什么普通 Angular Route Lazy Loading 对 Spartacus 不够

普通 Angular 项目可能这样设计：

```text
/
    HomeModule

/products
    ProductModule

/account
    AccountModule
```

于是 Angular Router 很容易知道：

```ts
{
  path: 'account',
  loadChildren: () =>
    import('./account/account.module')
}
```

用户没有进入 `/account`：

```text
AccountModule
    ↓
不下载
```

这非常自然。

但 Spartacus 的实际情况不同。

例如访问：

```text
/electronics-spa/en/USD/
```

Angular Router 可能只知道：

```text
这是一个 CMS page
```

真正的页面结构需要从 SAP Commerce CMS 获取。

CMS 返回：

```text
HeaderSlot
    SearchBoxComponent
    NavigationComponent

Section1
    SimpleResponsiveBannerComponent

Section2
    ProductCarouselComponent

Footer
    FooterNavigationComponent
    NewsletterComponent
```

甚至第二天业务人员可以在 Backoffice / SmartEdit 中把：

```text
NewsletterComponent
```

删除，再增加：

```text
CustomPromotionComponent
```

这意味着：

> **页面需要什么 JavaScript，不完全由 Angular Route 决定，而由 CMS 内容决定。**

所以 Spartacus 官方的设计思想是：

```text
Angular Route
      ↓
CMS Page
      ↓
CMS Component Type
      ↓
需要什么功能？
      ↓
动态加载相应代码
```

这正是 Spartacus 引入 CMS-driven lazy loading 的根本原因。[SAP GitHub](https://sap.github.io/spartacus-docs/lazy-loading-guide/?utm_source=chatgpt.com)

---

# 2. CMS Component Lazy Load 的意图

最典型的配置就是你最近研究的这种：

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

如果不是 lazy：

```ts
import { MyComponent } from './my-component/my-component';

provideConfig({
  cmsComponents: {
    MyComponent: {
      component: MyComponent
    }
  }
});
```

两者最大的区别发生在 **build time**。

静态 import：

```text
main.js
│
├── Spartacus core
├── MyComponent
├── MyComponent dependency
├── Other Component
└── ...
```

而动态 import：

```text
main.js

my-component.chunk.js
```

只有 CMS 真正要求创建：

```text
MyComponent
```

时，Spartacus 的 `LazyComponentHandler` 才执行：

```ts
import(...)
```

下载对应 chunk。SAP 官方明确指出，CMS component lazy loading 是通过在 CMS mapping 中使用 dynamic import 实现的，底层由 `LazyComponentHandler` 处理。[SAP GitHub](https://sap.github.io/spartacus-docs/lazy-loading-guide/?utm_source=chatgpt.com)

因此它的意图主要是：

```text
减少 main bundle
        ↓
减少首次网络下载
        ↓
减少 JavaScript parse
        ↓
减少 JavaScript compile
        ↓
减少 JavaScript execute
        ↓
更快进入可交互状态
```

SAP 官方特别提到，这种 code splitting 对复杂应用以及低性能移动设备上的 **Time To Interactive** 很有帮助。[SAP GitHub](https://sap.github.io/spartacus-docs/lazy-loading-guide/?utm_source=chatgpt.com)

---

# 3. Feature Module Lazy Load 的目标比 Component Lazy Load 更大

假设存在一个 Organization 功能。

它包含：

```text
Organization Feature
│
├── Components
│   ├── UserListComponent
│   ├── BudgetListComponent
│   ├── CostCenterComponent
│   └── PermissionComponent
│
├── Services
│   ├── UserService
│   └── BudgetService
│
├── NgRx
│   ├── Actions
│   ├── Reducers
│   ├── Effects
│   └── Selectors
│
├── OCC
│   ├── Adapters
│   └── Connectors
│
└── Config
```

如果只 lazy load：

```text
UserListComponent
```

那么可能仍然有很多代码已经进入 main bundle：

```text
Organization NgRx
Organization OCC
Organization services
Organization configuration
```

所以 Spartacus 又增加了一层：

> **Feature Module Lazy Loading**

官方列出的目标非常明确：

- lazy load component code；
- lazy load core code，包括 NgRx state；
- feature 第一次真正需要时才加载；
- feature 只初始化一次；
- 支持共享的 lazy-loaded dependency modules。[SAP Help Portal](https://help.sap.com/docs/SAP_COMMERCE_COMPOSABLE_STOREFRONT/eaef8c61b6d9477daf75bff9ac1b7eb4/6ae18e81bc8542b8885bb10bb046d5c8.html?utm_source=chatgpt.com)

典型配置：

```ts
provideConfig({
  featureModules: {
    organization: {
      module: () =>
        import('@spartacus/my-account/organization').then(
          m => m.OrganizationModule
        ),

      cmsComponents: [
        'OrderApprovalListComponent',
        'ManageBudgetsListComponent',
        'ManageCostCentersListComponent',
        'ManagePermissionsListComponent',
        'ManageUnitsListComponent',
        'ManageUsersListComponent'
      ]
    }
  }
});
```

运行时可能发生：

```text
CMS 返回
ManageUsersListComponent
        ↓
Spartacus 查询 cmsComponents
        ↓
发现它属于 organization feature
        ↓
organization feature 尚未加载
        ↓
import('@spartacus/my-account/organization')
        ↓
下载 JS chunk
        ↓
创建 OrganizationModule
        ↓
注册 services / providers / NgRx / CMS mapping
        ↓
创建 ManageUsersListComponent
```

这个思路就比单个 component lazy loading 完整得多。

---

# 4. 两者最本质的区别

可以用这张表理解：

| 对比 | CMS Component Lazy Load | Feature Module Lazy Load |
|---|---|---|
| lazy load 单位 | Component | Feature / Module |
| 典型配置 | `cmsComponents.xxx.component` | `featureModules.xxx.module` |
| Dynamic import | Component class | Angular module / feature |
| 是否加载 UI | 是 | 是 |
| 是否能同时带入 services | 通常依赖 import graph | 是 |
| 是否能带入 NgRx state | 通常不是主要目的 | 是 |
| 是否能带入 OCC layer | 通常不是主要目的 | 是 |
| 触发者 | CMS 请求该 component | CMS 请求属于 feature 的 component，或 feature API 被访问 |
| 粒度 | 非常细 | 较粗 |
| 主要目标 | 减少单个 CMS UI 代码 | 整个业务能力按需加载 |

一个非常形象的比喻：

### Component lazy loading

像去工具箱取一把电钻：

```text
我要 Drill
    ↓
只拿 Drill
```

### Feature module lazy loading

则像：

```text
我要装修浴室
    ↓
把 Bathroom Toolkit 整套拿出来
    ├── Drill
    ├── Screwdriver
    ├── Measurement
    ├── Pipes
    └── Accessories
```

如果这个 session 根本没有使用这个功能：

```text
整个工具箱都不用搬出来。
```

---

# 5. 为什么 Spartacus 需要两种机制，而不是只保留 Feature Lazy Loading

因为不同功能的最佳拆分粒度不同。

例如：

```text
Footer
 ├── FooterNavigationComponent
 ├── NewsletterComponent
 └── CustomLegalComponent
```

假设：

```text
CustomLegalComponent
```

只是一个独立 UI，没有：

```text
NgRx
OCC
复杂 service
多个相关 component
```

那么直接：

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

很合理。

没必要为了一个 20 KB 的 component 建造：

```text
CustomLegalRootModule
CustomLegalCoreModule
CustomLegalOccModule
CustomLegalComponentsModule
CustomLegalFeatureModule
```

反过来，如果是：

```text
Product Configurator
Organization
Checkout
Order
Cart
User Account
```

这种完整业务域，那么只 lazy load 一个 component 就太浅了。

它们往往涉及：

```text
UI
 +
Facade
 +
Service
 +
Connector
 +
Adapter
 +
NgRx
 +
Effects
 +
Config
```

因此 Feature lazy loading 更合理。

SAP 甚至通过 **Proxy Facade** 进一步解决了这个问题：调用 facade 的组件不需要知道背后的实现是否已经加载；访问 facade 时，可以触发相应 feature 的加载和初始化。[SAP Help Portal](https://help.sap.com/docs/sap_commerce_composable_storefront/eaef8c61b6d9477daf75bff9ac1b7eb4/f44487ba0e984e129039a40d41bf81b8.html?utm_source=chatgpt.com)

---

# 6. 一个特别重要的概念：Lazy Loading ≠ Deferred Rendering

这一点与你最近分析的 Spartacus SSR 问题直接相关。

很容易把：

```text
lazy loading
```

理解成：

> 页面滚动到那里以后才渲染。

实际上不是一回事。

Spartacus 至少存在三个容易混淆的概念：

```text
Code Lazy Loading
Deferred Component Rendering
Image Lazy Loading
```

它们解决不同问题。

---

## Code Lazy Loading

例如：

```ts
component: () => import('./footer.component')
```

解决：

```text
什么时候下载 / 初始化 JavaScript code？
```

触发条件可以简单到：

```text
CMS 需要这个 component
```

**不要求进入 viewport。**

---

## Deferred Loading

Spartacus 的 deferred loading 解决的是：

```text
什么时候真正 instantiate / render CMS component？
```

SAP 官方说明，deferred loading 可以让 viewport 外面的 CMS components 暂不创建，也会延迟相关数据请求。它主要由 page slot 和 viewport 状态驱动。[SAP Help Portal](https://help.sap.com/docs/SAP_COMMERCE_COMPOSABLE_STOREFRONT/eaef8c61b6d9477daf75bff9ac1b7eb4/defb67534a094c9bb0ae83423d1e2561.html?utm_source=chatgpt.com)

也就是说：

```text
Lazy Loading
关注 JavaScript code

Deferred Loading
关注 component rendering
```

这是两个正交维度。

---

## Image Lazy Loading

例如：

```html
<img loading="lazy">
```

关注：

```text
什么时候请求 image resource
```

这又是第三件事情。SAP 也单独提供了 image loading strategy。[SAP Help Portal](https://help.sap.com/docs/COMPOSABLE_STOREFRONT_TUA/6c37b295037d4a9c92c5b4481e4f6aff/5c37d465eb214e5ab3eee14f15366f8e.html?utm_source=chatgpt.com)

---

# 7. 所以 Footer Component 配成 lazy，真正的设计意图是什么？

结合你最近研究的那个案例：

```text
Footer slot
   ↓
CMS component
   ↓
component: () => import(...)
```

它的原始设计意图通常不是：

> Footer 在下面，所以等用户滚到底部才执行。

而是：

> **不要把 Footer 对应 component implementation 强制打进 initial bundle；如果 CMS 页面确实需要这个 component，再加载其 JavaScript chunk。**

两句话差别非常大。

比如：

```text
Page
├── Header
├── Banner
├── Product Carousel
├── Recommendation
└── Footer
```

如果 CMS 在 SSR 阶段就决定：

```text
FooterComponent 需要被创建
```

那么：

```ts
import('./footer.component')
```

可能立即执行。

即使 Footer 位于页面最下面。

所以：

```text
位置在 below-the-fold
```

并不天然等于：

```text
dynamic import 等滚动后执行
```

只有再结合 Spartacus 的：

```text
Deferred Loading
```

或者其他 viewport/intersection 策略，才能实现真正的：

```text
用户接近 Footer
        ↓
create component
        ↓
触发 dynamic import
```

---

# 8. 这也解释了为什么 Spartacus 不只是 Angular Route Lazy Loading

整个设计链条其实非常漂亮：

```text
Traditional Angular

URL
 ↓
Router
 ↓
Route Module
 ↓
Component
```

而 Spartacus：

```text
URL
 ↓
Angular Router
 ↓
CMS Page
 ↓
CMS Slots
 ↓
CMS Component Types
 ↓
Spartacus component / feature mapping
 ↓
Dynamic import
 ↓
JS Chunk
 ↓
Feature / Component
```

换句话说：

> Spartacus 把 **`页面需要什么代码`** 的部分决定权，从 Angular build-time route configuration 转移到了 **CMS runtime composition**。

这是它 lazy loading 架构最核心的设计思想。

SAP 官方自己的表述也是：由于 Spartacus 大量由 CMS 驱动，因此在 build time 无法仅凭 route 决定完整应用逻辑，业务用户还可以之后修改页面结构，所以需要 CMS-aware 的 lazy-loading 方案。[SAP GitHub](https://sap.github.io/spartacus-docs/lazy-loading-guide/?utm_source=chatgpt.com)

---

# 9. 从 Bundle 的角度看，两种 lazy loading

假设整个 storefront 有：

```text
Core                    400 KB
Header                   50 KB
Footer                    80 KB
Product                  200 KB
Checkout                 350 KB
Organization             500 KB
Configurator             700 KB
```

全部 eager load：

```text
main.js
≈ 2.28 MB
```

即使用户只是：

```text
打开首页
→ 看几个商品
→ 离开
```

浏览器仍可能承担：

```text
Organization 500 KB
Configurator 700 KB
Checkout 350 KB
```

的：

```text
Download
Decompress
Parse
Compile
Execute
```

成本。

Feature lazy loading 后可能变成：

```text
main.js                 650 KB

checkout.js             350 KB
organization.js         500 KB
configurator.js         700 KB
```

用户没有进入这些业务：

```text
这些 chunk 根本不下载。
```

SAP 的 performance best practices 也明确建议利用 code splitting，让 storefront 每个页面只加载实际需要的 JavaScript chunks。[SAP Help Portal](https://help.sap.com/docs/SAP_COMMERCE_COMPOSABLE_STOREFRONT/eaef8c61b6d9477daf75bff9ac1b7eb4/baaf419226424c22b8dbf5c113a7d93d.html?utm_source=chatgpt.com)

---

# 10. 最终可以把 Spartacus 的设计意图浓缩成一句话

我会把整个机制归纳为：

```text
CMS Component Lazy Load
        =
`这个 UI 实现现在真的需要吗？`

Feature Module Lazy Load
        =
`这个完整业务能力现在真的需要吗？`
```

两者共同实现的是：

```text
Build Time
    ↓
把应用切成多个 chunks

Runtime
    ↓
CMS 告诉 Spartacus 当前页面需要什么

Spartacus
    ↓
只激活当前需要的 Component / Feature

Result
    ↓
Smaller initial bundle
Less JS parsing
Less JS execution
Lower memory pressure
Faster startup / TTI
```

而你最近分析的 **SSR + Footer lazy component + native `import()` + application stability** 问题，恰恰是在这个设计之上暴露出来的另一个维度：

> **Lazy loading 的目的本身是 code splitting 和性能优化；但在 SSR 中，只要 dynamic import 参与当前页面渲染，它就变成了 SSR 必须正确等待的异步工作。**

所以不能因为它叫 `lazy component` 就认为 SSR 可以不等它。对于 SSR 来说，真正重要的问题变成：

```text
这个 lazy component
      ↓
是不是当前 CMS page 的组成部分？
      ↓
如果是
      ↓
SSR 是否认为它属于 rendering pending work？
```

这正是你前面那个 `LazyComponentHandler.launcher → from(componentMapping.component()) → native import() → Angular pending task` 问题的核心。换句话说，**SAP 引入 lazy loading 的初衷是减少 initial JavaScript 成本，而不是让 SSR 可以在 lazy component 尚未 resolve 时提前宣告页面渲染完成。** [SAP GitHub](https://sap.github.io/spartacus-docs/lazy-loading-guide/?utm_source=chatgpt.com)

SAP Spartacus 同时提供 CMS Component Lazy Load 和 Feature Module Lazy Load，背后的核心意图其实是一致的：

SAP Spartacus 的 lazy load Component

紫薇堂堂主

前端

开发工具

架构设计

Spartacus通过CMSComponentLazyLoad与FeatureModuleLazyLoad实现CMS驱动的代码分割，前者按组件细粒度加载UI，后者按业务功能加载完整模块含NgRx与OCC层，避免初始bundle过大。两者由CMS运行时需求触发，而非Angular路由，确保用户仅下载当前页面所需代码，显著提升启动速度与移动端TTI。

代码解释

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

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

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

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

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

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

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

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

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

社区新版编辑器体验调研

Spartacus通过CMSComponentLazyLoad与FeatureModuleLazyLoad实现CMS驱动的代码分割，前者按组件细粒度加载UI，后者按业务功能加载完整模块含NgRx与OCC层，避免初始bundle过大。两者由CMS运行时需求触发，而非Angular路由，确保用户仅下载当前页面所需代码，显著...

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

SAP Spartacus 的 lazy load Component

SAP Spartacus 的 lazy load Component

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐