Angular自定义CURRENT_USER注入提供者是否属于不良实践？

在我的Angular应用中，我将登录用户以BehaviorSubject的形式存储在AuthenticationService中：

export class AuthenticationService {

  private user$$ : BehaviorSubject<AppUser>;

  // ...

  // simplified version of actual method
  authenticateUser(username : string) : Observable<AppUser> {

     return this.http.get(AUTH_URL)
       pipe(
         tap(user => this.user$$.next(user)),
         ...
       );
  }

  getCurrentUser() : Observable<AppUser> {
    // only provide to end as read-only observable
    return this.user$$.asObservable();
  }
}

但由于许多组件都需要获取用户信息，我通常会在这些组件中注入AuthenticationService：

private user : AppUser;

constructor(authService : AuthenticationService) {}

ngOnInit() : void {

  this.authService.getCurrentUser()
    pipe(
      tap((user) => this.user = user),
      // etc
    )
    .subscribe();

}

我希望创建一个自定义提供者（CURRENT_USER注入令牌代码已省略）：

@NgModule({
  // ...
  providers: [
    { provide : CURRENT_USER, useFactory: (authenticationService : AuthenticationService) => authenticationService.getCurrentUser(), deps: [AuthenticationService] }
  ]
})

这么做的好处是可以将各组件与AuthenticationService解耦，但我想了解这种做法是否属于不良实践，是否会引发内存泄漏等不良后果？

这种做法不属于不良实践，反而在多数场景下是推荐的解耦方案，但需要注意细节规避潜在问题：

1. 解耦的合理性 #

通过自定义注入令牌CURRENT_USER提供用户Observable，能让组件只依赖用户数据流本身，而非具体的AuthenticationService，优势包括：

• 后续若需替换用户状态管理方式（比如改用NgRx），只需更新CURRENT_USER的提供者实现，组件无需修改
• 单元测试时，可直接模拟CURRENT_USER的数据流，无需Mock整个AuthenticationService

2. 内存泄漏的风险 #

这种做法本身不会直接引发内存泄漏，但组件订阅CURRENT_USER时需遵循Angular订阅管理规范：

• 组件销毁时必须取消订阅，比如用takeUntil配合ngOnDestroy钩子
• 更推荐使用async管道，Angular会自动管理订阅的销毁，示例如下：
  模板中：

  <div *ngIf="currentUser$ | async as user">
    {{ user.username }}
  </div>
  

  组件中：

  constructor(@Inject(CURRENT_USER) public currentUser$: Observable<AppUser>) {}
  

  这种方式完全无需担心内存泄漏问题。

3. 关键注意事项 #

• 确保AuthenticationService是单例（通常在根模块提供），这样CURRENT_USER对应的Observable全局唯一，所有组件订阅的是同一数据流
• 工厂函数返回asObservable()的结果，保证了Observable的只读性，避免组件意外修改用户状态，符合封装原则
• 若应用存在多环境或多用户状态场景，可通过useFactory根据条件返回不同Observable，灵活性更高

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