关于Spartacus库私有API使用及非公开类临时扩展的技术问询

我之前在项目里也碰到过类似的需求——想要扩展的Spartacus类不在公开API里，没法直接从官方包导入，同时还在等核心团队把它纳入公开API的回复。这里给你几个实用的应急方案，不过要提前说明：这些都是权宜之计，优先推荐等官方正式公开API，避免后续版本升级时出现兼容性问题。

方案1：直接导入私有文件路径 #

Spartacus的私有类通常存放在包内的src目录下的深层路径里，你可以直接通过完整的相对路径导入。比如：

// 示例：导入core包下的某个私有类
import { SomeClass } from '@spartacus/core/src/some/internal/path/SomeClass';

export class MyExtendedClass extends SomeClass {
  // 你的扩展逻辑
}

• 优点：实现最快，不需要额外封装，直接就能扩展目标类。
• 缺点：私有路径完全不受官方兼容性保障，Spartacus升级时可能会修改文件结构或类的实现，导致代码报错。
• 注意：一定要在代码里加醒目的注释，标记这是临时使用的私有API，后续要替换成公开导入路径。

方案2：创建封装层隔离依赖 #

为了减少私有路径变动带来的影响，可以给目标私有类做一层包装，项目里所有的扩展都基于这个包装类：

// 临时封装文件：wrapped-some-class.ts
import { SomeClass } from '@spartacus/core/src/some/internal/path/SomeClass';

// 封装私有类，后续官方公开后只需修改这里的导入
export class WrappedSomeClass extends SomeClass {
  // 可以在这里提前实现通用扩展逻辑，或者直接转发父类方法
}

然后在项目的其他地方都导入WrappedSomeClass进行扩展：

import { WrappedSomeClass } from './wrapped-some-class';

export class MyExtendedClass extends WrappedSomeClass {
  // 你的业务扩展逻辑
}

• 优点：把私有API的依赖集中在一个文件里，后续官方公开API后，只需要修改封装文件的导入路径，其他业务代码不用动。
• 缺点：多了一层封装，需要额外维护这个中间类。

方案3：利用Angular依赖注入覆盖（如果类支持DI） #

如果目标私有类是通过Angular的依赖注入提供的，你可以通过自定义Provider来替换成你的扩展类：

import { SomeClass } from '@spartacus/core/src/some/internal/path/SomeClass';

@Injectable()
export class ExtendedSomeClass extends SomeClass {
  // 你的扩展逻辑，比如重写父类方法
  override someMethod(): void {
    super.someMethod();
    // 自定义逻辑
  }
}

// 在你的Feature模块或Root模块中配置Provider
@NgModule({
  providers: [
    { provide: SomeClass, useClass: ExtendedSomeClass }
  ]
})
export class MyCustomModule {}

• 优点：符合Angular的DI设计模式，扩展方式更优雅，不需要直接在业务代码里导入私有类。
• 缺点：依赖于目标类的DI配置，如果私有类没有被标记为@Injectable，或者它的注入Token是私有的，这个方法可能无法生效。

方案4：复制私有类源码到本地（谨慎使用） #

如果目标私有类的代码量不大，且依赖的其他私有API较少，可以直接把类的源码复制到你的项目中，然后基于本地副本进行扩展。

• 优点：完全脱离Spartacus私有API的依赖，不会因为版本升级受影响。
• 缺点：后续官方公开API后，需要手动同步本地副本和官方版本的差异，维护成本高；如果类依赖其他私有类，这个方法会变得非常繁琐。

重要提醒 #

无论使用哪种临时方案，都要：

1. 在代码中添加清晰的注释，标记这是临时使用私有API的应急方案，方便后续替换。
2. 每次Spartacus版本升级时，仔细检查相关私有类的代码变化，及时调整你的实现。
3. 持续跟进你提交的Issue，一旦官方将该类纳入公开API，立即替换成官方的公开导入方式。

内容的提问来源于stack exchange，提问作者Krzysztof Platis