Angular/TypeScript中用BehaviourSubject做类成员是否为反模式

这种写法不属于严格意义上的反模式，但属于RxJS的过度使用场景，除了极特殊的高实时性要求场景外，不推荐在业务代码中大面积使用。

核心负面影响 #

• 代码维护成本陡增：普通属性的直接赋值、读取逻辑全部要改成响应式调用，原本foo.bar = 'test'的赋值要写成foo.bar.next('test')，同步读取值还要调用foo.bar.getValue()，涉及批量属性更新、对象序列化传参时，会产生大量冗余的取值/赋值包装代码，团队协作时的新人适配成本很高。
• 内存泄漏隐患增加：虽然async管道会自动回收订阅，但业务逻辑中只要存在对这些属性Subject的手动订阅，任意一个遗漏取消订阅都会造成内存泄漏；类的属性越多，这类泄漏点的排查难度越高。
• 调试效率大幅下降：普通对象可以直接在控制台打印、断点查看属性值，全量替换为BehaviorSubject后，调试时必须逐个展开Subject实例才能拿到当前持有的值，接口序列化、本地缓存存储时还要额外做全量属性的值提取转换，额外增加无意义的工作量。
• 无意义的性能开销：每个BehaviorSubject实例都要维护订阅者列表、处理值广播逻辑，当一个类存在十几个甚至几十个这类属性时，实例初始化、值更新的额外开销会持续累积，往往远超过你想规避的变更检测成本。

更合理的实现方案 #

• 优先用Angular原生能力解决变更检测问题：给组件配置changeDetection: ChangeDetectionStrategy.OnPush，动态更新的状态使用不可变数据更新（修改值时生成新的对象/数组引用），Angular会自动触发对应组件的视图刷新，完全不需要手动触发检测，也不需要引入大量Subject。
• 如果确实需要用响应式状态管理，不要拆分单个属性，给整个类的状态用单个BehaviorSubject承载即可：

class Foo {
  private readonly _state$ = new BehaviorSubject({
    bar: '' as string,
    bas: new Date()
  });
  // 对外暴露只读状态流，供模板用async管道订阅
  readonly state$ = this._state$.asObservable();

  // 统一的状态更新方法
  patchState(partial: Partial<{bar: string; bas: Date}>) {
    this._state$.next({
      ...this._state$.getValue(),
      ...partial
    })
  }
}

模板中使用时直接通过async管道解包即可：

<ng-container *ngIf="foo.state$ | async as state">
  <p>{{ state.bar }}</p>
  <p>{{ state.bas | date }}</p>
</ng-container>

• 仅当单个属性存在独立的流式处理需求（比如需要单独做防抖、节流、和其他数据流做组合联动、有多个独立订阅者）时，才将这个属性单独定义为BehaviorSubject，不要全量属性无脑替换。

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