Angular模板中Getter、方法与Signal的选择：实践与性能分析

我不想在Angular模板的*ngIf里写内联逻辑（比如<div *ngIf="a === 3 && b === 'foo'"></div>），通常会写个专用方法：

public isOk(): boolean {
  return a === 3 && b === 'foo'
}

模板就变成<div *ngIf="isOk()"></div>。这种做法合理吗？用方法还是Getter更合适？二者的优缺点分别是什么？

Getter的写法如下：

public get isOk(): boolean {
  return a === 3 && b === 'foo'
}

模板对应改成<div *ngIf="isOk"></div>。

一、方法（Method）的优缺点 #

• 优点：
  • 写法直观，支持传入参数（如果后续需要根据动态参数做判断，灵活性更高）
  • 方法名语义清晰，能直接体现判断逻辑的用途
• 缺点：
  • 变更检测时频繁执行：只要组件触发变更检测（比如用户交互、其他数据更新），模板里的方法就会被调用一次，哪怕依赖的a、b没有变化，可能带来不必要的性能损耗
  • 无法被OnPush等变更检测优化策略识别依赖，容易产生冗余执行

二、Getter的优缺点 #

• 优点：
  • 模板调用更简洁，无需加括号，符合Angular模板访问属性的习惯
  • 语法上更贴近组件属性，可读性更好
• 缺点：
  • 和方法一样，变更检测周期内会重复执行：只要组件进入变更检测流程，Getter就会被触发，不管依赖变量是否有变化
  • 不支持传参，只能基于组件内部固定属性做判断，灵活性不足

三、Signal + Computed：性能最优方案 #

Angular引入Signal后，这类场景的最优解是使用Signal配合computed。它们不会像方法和Getter那样绑定到变更检测循环，只有当依赖的Signal值发生变化时，computed才会重新计算，性能开销更小。

示例代码 #

组件类代码

export class SampleComponent {
  constructor(private cdr: ChangeDetectorRef) {}

  a = 3;
  b = 'foo'

  asignal = signal(3);
  bsignal = signal('foo');

  get isOkGetter(): boolean {
    console.log('getter');
    return this.a === 3 && this.b === 'foo';
  }

  isOkMethod(): boolean {
    console.log('method');
    return this.a === 3 && this.b === 'foo';
  }

  isOkSignal = computed(() => {
    console.log('signal');
    return this.asignal() === 3 && this.bsignal() === 'foo'
  });

  changeSomething() {
    this.a = 5;
    this.asignal.update(() => 5);
    // 模拟变更检测循环
    this.cdr.markForCheck();
  }
}

模板代码

<div>
  <p>getter: {{ isOkGetter }}</p>
  <p>method: {{ isOkMethod() }}</p>
  <p>signal: {{isOkSignal()}}</p>
  <button (click)="changeSomething()">修改数据</button>
</div>

执行表现说明 #

点击按钮修改数据后，触发变更检测时：

• isOkGetter和isOkMethod()会被重新调用（控制台会打印对应的日志）
• isOkSignal仅在依赖的asignal或bsignal值变化时才会重新计算，避免了冗余执行

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