Angular中是否需要为所有Observable连接使用Subscription对象管理？

直接订阅不保存引用、不执行销毁的实践判定 #

这种写法不能一概而论判定为不良实践，是否需要手动取消订阅取决于你订阅的Observable类型：

• 有限流：比如HttpClient返回的单次请求、of()/from()创建的固定个数值的流，这类流在所有值发射完成后会自动触发complete回调，自动释放订阅资源，不会产生订阅本身的内存泄漏。但仍存在逻辑隐患：如果组件销毁后流才返回结果触发回调，回调逻辑如果操作已销毁的组件属性、不存在的DOM节点，可能引发运行时报错或非预期的逻辑执行。
• 无限流：比如interval定时器、全局事件监听、路由参数/query参数订阅、业务自定义的长驻Subject这类不会自动complete的流，不保存订阅引用、不手动取消会导致组件实例被订阅持续持有，无法被垃圾回收，直接造成内存泄漏，这种场景下直接订阅的写法属于明确的不良实践。

所以不需要强制把每一个Observable订阅都赋值给变量显式取消，但建议统一处理订阅销毁逻辑，避免边界场景的问题。

同一Subscription变量重复赋值的潜在缺陷 #

这种写法存在明确的风险，核心问题有两个：

• 前序订阅引用丢失无法销毁：第一次赋值的订阅引用会被第二次赋值覆盖，如果你没有单独保存过前序订阅的引用，就无法对它执行取消操作，要是前序订阅是无限流、或者还在执行中，就会直接产生内存泄漏，ngOnDestroy中你只能取消最后一次赋值的订阅，前面的所有订阅都会被遗漏。
• 容易引发竞态问题：如果前后两个订阅都是异步请求，会出现后发的请求先返回、先发的请求后返回的情况，要是两个回调修改同一个组件变量，就会出现后返回的旧结果覆盖先返回的新结果的逻辑错误。

推荐的多订阅处理方式 #

不需要为每个订阅单独声明变量，可以用统一的订阅容器处理：

// 方式1：用Subscription容器统一管理
private subscriptions = new Subscription();

// 新增订阅时调用add方法添加
this.subscriptions.add(
  this.dataService.getAllUsers().subscribe()
);
this.subscriptions.add(
  this.dataService.getUserDetail(user.Id).subscribe()
);

// 销毁时统一取消所有订阅
ngOnDestroy(){
  this.subscriptions.unsubscribe();
}

// 方式2：用takeUntil操作符统一终止（更推荐的响应式写法）
private destroy$ = new Subject<void>();

this.dataService.getAllUsers()
  .pipe(takeUntil(this.destroy$))
  .subscribe();
this.dataService.getUserDetail(user.Id)
  .pipe(takeUntil(this.destroy$))
  .subscribe();

ngOnDestroy(){
  this.destroy$.next();
  this.destroy$.complete();
}

内容的提问来源于stack exchange，提问作者Full Time Skeleton