如何解决CategoryService与FilterService构造函数的循环依赖问题？

你遇到的是典型的构造器注入循环依赖，两个服务互相依赖对方的实例，导致DI容器无法正常初始化。下面是几种实用的解决方法：

1. 提取共享逻辑到独立服务 #

如果两个服务存在共同依赖的业务逻辑或工具方法，把这部分代码抽离到一个新的独立服务（比如CommonService、CategoryFilterUtils），让FilterService和CategoryService都依赖这个新服务，替代互相依赖的关系。

比如，假设两个服务都需要处理分类数据的过滤规则，就把这部分规则逻辑放到新服务里，两个服务只需要注入这个新服务即可，不再直接依赖对方。

2. 改用延迟注入/属性注入 #

放弃构造器注入，改用setter方法注入或者按需获取依赖，避免在实例化阶段就要求对方的实例：

修改FilterService示例： #

export class FilterService implements IFilterService
{
  protected categoryService?: ICategoryService;

  // 提供setter方法注入依赖
  setCategoryService(service: ICategoryService): void {
    this.categoryService = service;
  }

  // 使用依赖前先做校验
  applyFilter() {
    if (!this.categoryService) {
      throw new Error('CategoryService未初始化');
    }
    // 这里正常使用this.categoryService
  }
}

修改CategoryService示例： #

export class CategoryService implements ICategoryService
{
  protected filterService?: IFilterService;

  constructor() {
    // 构造器不再注入依赖
  }

  setFilterService(service: IFilterService): void {
    this.filterService = service;
  }
}

然后在DI容器初始化时，先创建两个实例，再通过setter互相注入，打破循环。

3. 重构职责，解耦依赖 #

重新审视两个服务的职责划分：

• FilterService的核心职责是处理过滤逻辑，是否真的需要直接依赖CategoryService？
• CategoryService的核心职责是管理分类，是否必须调用FilterService的方法？

比如，如果FilterService需要分类数据，可以让上层调用者（比如控制器、业务逻辑层）先从CategoryService获取数据，再传递给FilterService的方法，而不是让FilterService主动去依赖CategoryService获取数据。

4. 利用DI容器的延迟解析能力 #

如果使用NestJS、Angular这类自带DI容器的框架，可以通过工厂函数或延迟提供者来解决：

以NestJS为例，用工厂函数创建服务实例：

// FilterService的提供者配置
{
  provide: FilterService,
  useFactory: (categoryService: CategoryService) => {
    const filterService = new FilterService();
    filterService.setCategoryService(categoryService);
    return filterService;
  },
  inject: [CategoryService]
}

// CategoryService的提供者配置
{
  provide: CategoryService,
  useFactory: () => new CategoryService()
}

容器会先创建CategoryService实例，再传入工厂函数创建FilterService，最后通过setter完成依赖注入。

内容的提问来源于stack exchange，提问作者Dima Kambalin