Angular组件间通信：不使用RxJS/Signals是否有隐患？

架构老林

2026-6-28

Angular无RxJS/Signals的跨组件通信方式存在哪些弊端？

我搜索Angular跨组件通信的示例时，发现几乎都在服务里用RxJS（现在也有用Signals的），但我写了个不用这两者的示例，两个组件依然能感知到counter的变化。我知道RxJS/Signals是Angular的推荐做法，但想了解除此之外的实际原因——这种方式会不会引发问题或bug？

示例代码

服务代码

import { Injectable } from '@angular/core';

@Injectable({
  providedIn: 'root',
})
export class MyService {
  private counter: number = 0;

  increment() {
    this.counter += 1;
  }

  getValue() {
    return this.counter;
  }
}

Component1代码

import { Component } from '@angular/core';
import { MyService } from './MyService';

@Component({
  selector: 'component1',
  standalone: true,
  template: `
    <h1>Component 1</h1>
    Current Value: {{ valueFromService }}
    <button (click)="increment()">Click to increment</button>
  `,
})
export class Component1 {
  constructor(private myService: MyService) {}

  get valueFromService() {
    return this.myService.getValue();
  }

  increment() {
    this.myService.increment();
  }
}

Component2代码

import { Component } from '@angular/core';
import { MyService } from './MyService';

@Component({
  selector: 'component2',
  standalone: true,
  template: `
    <h1>Component 2</h1>
    Current Value: {{ valueFromService }}
  `,
})
export class Component2 {
  constructor(private myService: MyService) {}

  get valueFromService() {
    return this.myService.getValue();
  }
}

这种方式的核心问题与弊端

变更检测依赖触发时机，异步场景会失效
你这个示例能正常运行，是因为点击按钮属于用户交互，会自动触发Angular的变更检测周期，组件里的getter会被重新调用，自然能拿到最新的counter值。但如果服务里的counter是通过异步操作更新的——比如HTTP请求返回后修改、定时器自动累加——这时候不会自动触发变更检测，Component2的视图就会停留在旧值上。你得手动调用ChangeDetectorRef的方法来强制更新，不仅增加代码量，还容易在复杂场景下遗漏，导致视图和数据不一致。
性能浪费，无意义计算增多
Angular的变更检测会在每个周期遍历组件的所有绑定，包括你写的valueFromService getter。不管counter有没有变化，只要变更检测跑起来，这个getter就会被调用。如果服务里的状态逻辑复杂，或者页面上有几十个依赖这个状态的组件，频繁的getter调用会带来不必要的性能开销。而RxJS Observable或Signals都是状态变化才通知，完全避免了这种无意义的计算。
状态变化难以追踪，排查bug成本高
用这种简单的get/set方式，你没法直接知道counter什么时候被修改了、被哪个组件修改了。一旦状态出现异常，你得挨个排查所有可能修改状态的地方，效率极低。而RxJS的管道可以加日志、Signals有专门的调试工具（比如Angular DevTools），能清晰追踪状态的变化流，定位问题快得多。
复杂场景下扩展性极差
当你的应用需要处理更复杂的状态逻辑——比如对counter做过滤、转换，或者多个状态相互依赖——这种手动get/set的方式会瞬间变得臃肿。比如要实现“只显示偶数counter”，你得在每个组件的getter里加判断；如果要做防抖处理，更是得自己写一堆逻辑。而RxJS的操作符（map、filter、debounceTime）、Signals的计算信号和效果函数，能轻松搞定这些需求，代码还更整洁。
违背Angular响应式设计思路
Angular从RxJS到Signals，一直主推响应式状态管理——状态变化时主动推送给订阅者，而不是让组件主动去拉取。长期来看，遵循框架的设计理念能让你的代码更符合团队的开发共识，新人接手也更容易上手，还能无缝结合AsyncPipe这类特性，减少手动管理订阅的麻烦。

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