Angular中computed信号与getter的差异及选型建议

Signals是Angular的前沿特性，很多开发者对以下两种写法的区别存在困惑：

写法一：使用 computed #

computed(() => `Result: ${this.someSignal()}`)

写法二：使用 getter #

get someGetter () { return `Result: ${this.someSignal()}` }

曾有观点认为启用ChangeDetectionStrategy.OnPush时getter不会执行，但实际并非如此——二者在该模式下表现一致。接下来我们拆解二者的核心差异，并给出选择建议：

核心差异 #

• 缓存机制不同
  computed会自动缓存计算结果，只有当它依赖的信号（比如示例中的someSignal）发生变化时，才会重新执行计算逻辑。而getter每次被调用时都会重新运行内部逻辑，哪怕依赖的信号没有任何变更。

• 响应式能力不同
  computed本身是一个信号，它会主动追踪依赖的信号变化，并且在自身更新时通知所有依赖它的观察者（比如模板绑定、其他信号或effect）。而getter只是普通的属性访问器，只有当组件触发变更检测时才会被重新调用，无法主动通知依赖它的代码返回值已变化。

• 执行时机不同
  computed的计算逻辑仅在首次被访问或者依赖信号发生变更时执行；而getter的逻辑会在每次被访问时执行——比如模板每次渲染、组件代码中每次调用这个getter时，都会重新运行。

• 可组合性不同
  computed作为信号，可以直接作为其他信号、effect或computed的依赖，轻松构建复杂的响应式数据流。而getter的返回值如果不是信号，无法直接加入响应式依赖链，必须在effect或computed等响应式上下文里调用才能被追踪。

选择建议 #

• 当你需要缓存计算结果，或者希望这个计算值能主动通知依赖它的代码发生变化时，优先用computed。比如处理复杂计算逻辑、需要在多个地方复用且依赖信号变化的场景。
• 当计算逻辑非常简单（比如只是简单的信号值包装或字符串拼接），且只会在组件变更检测周期内被访问时，用getter更轻便，不需要额外创建信号实例。
• 如果需要将这个计算值作为响应式数据流的一部分（比如作为其他信号的输入），必须使用computed——因为getter无法参与响应式依赖追踪。

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