这个错误几乎肯定是代码逻辑问题，而非Angular的基础配置问题——毕竟配置错误一般不会触发栈溢出这类运行时循环调用问题。咱们一步步拆解原因和修复方案：

错误根源定位 #

从你提供的错误栈来看，问题出在RxJS的订阅取消（unsubscribe）流程里：UnsubscriptionErrorImpl初始化时调用Array.map触发了栈溢出，结合后续的BehaviorSubject.next调用链，核心原因大概率是订阅与取消订阅之间出现了无限循环触发。常见的场景包括：

• 某个订阅的next回调里触发了会导致当前订阅被取消的操作，而取消订阅的逻辑又反过来触发了next事件，形成闭环；
• BehaviorSubject的next调用在订阅回调里被重复触发，每次触发都会创建新的订阅/触发取消操作，最终把调用栈撑爆。

具体排查方向 #

• 检查BehaviorSubject的使用逻辑：重点看所有在订阅回调里调用next的代码块，判断是否存在“更新Subject值→触发订阅回调→再次更新Subject值”的循环；
• 核查订阅取消逻辑：比如在ngOnDestroy里手动取消订阅时，是否不小心触发了某个会重新激活订阅的操作？或者使用takeUntil这类操作符时，是否错误地在订阅回调里触发了销毁信号的Subject？
• 追踪UnsubscriptionError的触发场景：这个错误通常是取消订阅时抛出了多个错误，而错误处理逻辑又引发了新的循环，比如自定义错误处理函数里又触发了订阅取消操作。

修复方案 #

1. 打破循环触发链
   如果发现是BehaviorSubject.next在订阅回调里被重复调用，一定要加条件判断，只在值真正变化时才触发next：

// 错误示例：无条件调用next导致无限循环
this.mySubject.subscribe(value => {
  this.mySubject.next(value + 1);
});

// 修复：仅当新值与当前值不同时才触发更新
this.mySubject.subscribe(value => {
  const newValue = value + 1;
  if (newValue !== this.mySubject.value) {
    this.mySubject.next(newValue);
  }
});

2. 规范订阅管理
   尽量使用Angular的async管道自动管理订阅，减少手动unsubscribe的操作；如果必须手动取消，确保取消逻辑不会触发新的订阅回调——比如避免在unsubscribe后调用会触发Subject更新的方法。

3. 调试数据流
   在关键的next调用和unsubscribe处添加日志，或者用RxJS的tap操作符跟踪数据流，明确调用链的循环路径：

this.mySubject.pipe(
  tap(value => console.log('Subject更新值:', value)),
  takeUntil(this.destroy$)
).subscribe(value => {
  // 你的回调逻辑
});

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