Angular循环依赖处理最佳实践：双向依赖服务的架构优化方案

针对Angular中UserService和GroupService的双向依赖问题，行业内通用的解耦方案有以下4种，可根据业务复杂度选择：

1. 抽取关联逻辑到第三方中间服务 #

这是最易落地、耦合度最低的方案：

• 梳理两个服务互相调用的逻辑，全部拆分到独立的UserGroupRelationService中，比如「查询用户所属用户组」「查询指定组的用户列表」「给用户绑定/解绑用户组」这类跨二者边界的逻辑，都收敛到这个中间服务
• 原有UserService仅保留用户本体的CRUD、用户身份校验、用户基础信息更新等不涉及用户组的逻辑
• 原有GroupService仅保留用户组本体的CRUD、组权限配置、组基础信息更新等不涉及用户的逻辑
• 两个原有服务都只依赖UserGroupRelationService，不再互相调用，直接消除循环依赖

2. 事件驱动解耦 #

适合调用逻辑不需要同步返回结果的场景：

• 新增全局的AppEventService，内置通用的RxJS Subject作为事件总线
• 当UserService触发用户删除、用户信息更新等需要通知用户组服务的操作时，仅向事件总线发布对应事件，不需要感知是否有服务订阅
• GroupService订阅事件总线中自己关心的用户事件，触发对应逻辑更新用户组数据，反之同理
• 两个服务仅依赖事件总线服务，完全不需要感知对方的存在

3. 依赖倒置+接口抽象 #

适合两个服务确实需要保留部分互相调用逻辑的场景：

• 分别定义IUserCoreService和IGroupCoreService两个接口，仅声明对方需要调用的方法，不要包含服务全量接口
• 借助Angular的InjectionToken声明注入标识，两个服务分别实现对应的接口，依赖注入时注入接口Token而非具体服务类
• 配合forwardRef的延迟注入能力，在不调整业务逻辑的前提下消除编译警告，这种方案属于轻度重构，耦合度比前两种高

4. 调整服务职责边界 #

大部分循环依赖本质是服务职责划分不合理导致的，你可以重新梳理边界：

• 比如把用户组相关的逻辑全部收敛到GroupService，UserService只返回用户基础ID，所有和组关联的查询都由上层组件或者中间服务调用GroupService传入用户ID完成，反过来也可以
• 强制砍掉其中一个服务对另一个的依赖，把跨边界的调用上移到组件或者聚合层

强制消除双向依赖、要求服务之间仅保留单向依赖是架构设计的通用原则，核心原因有4点：

• 可维护性更高：双向依赖的两个服务属于强绑定关系，修改任意一个服务的逻辑都可能影响另一个，也无法单独复用其中任意一个服务到其他项目，后续迭代的维护成本会指数级上升
• 可测试性更强：单元测试时双向依赖的服务无法单独Mock，测试UserService必须初始化完整的GroupService，反之同理，很容易出现一个服务的bug导致另一个服务的单测用例失败，排查成本极高
• 运行时更稳定：Angular提供的forwardRef等解决循环依赖警告的方案本质是延迟初始化，很容易出现业务逻辑在服务实例化完成前就调用其方法，导致无规律的运行时报错，这类问题排查成本远高于编译警告
• 架构扩展性更好：单向依赖的架构下，替换任意一个服务的实现成本极低，比如后续要把用户组逻辑替换为调用外部中台接口，只需要保证GroupService符合原有接口约定即可，完全不需要修改UserService的代码，双向依赖的架构下替换一个服务就要同步修改另一个服务的所有调用逻辑

内容的提问来源于stack exchange，提问作者Bokris Itzhak