mat-select搭配无trackBy的ngFor使用时浏览器冻结原因求解

底层原因拆解 #

1. Getter返回新引用触发ngFor重渲染
   你写的get priorities是属性getter，每次被访问时都会返回一个全新的数组，数组内的每个优先级对象也是全新的引用。Angular的*ngFor默认使用对象引用判断列表是否需要更新，每次检测到数组引用变化，就会销毁所有旧的mat-option节点，重新渲染完整的选项列表。

2. mat-select内部逻辑触发变更检测循环
   mat-select内部会监听选项列表的变化，当检测到mat-option节点被批量销毁重建时，会触发自身的变更检测逻辑：包括校验当前选中值是否匹配现有选项、更新下拉面板状态等。这个校验过程会再次访问模板中绑定的priorities getter，拿到新的数组引用，再次触发*ngFor的重渲染，两者互相触发就形成了死循环，最终导致浏览器冻结。

3. 为什么官方文档没有专门标注
   这个问题本质是Angular变更检测的通用问题，并非mat-select的专属bug：普通*ngFor渲染普通DOM元素时，就算数组引用变化触发重渲染，也不会额外触发新一轮的全局变更检测，最多只会有性能损耗不会卡死。只有mat-select这类内部对选项列表变更有监听逻辑的组件，才会把这个通用问题放大为死循环，因此官方没有单独将其列为mat-select的必用规则。

各解决方案的原理 #

• 逐个声明mat-option：没有使用*ngFor遍历数组，不会触发数组引用对比导致的批量重渲染，自然不会触发循环
• 使用原生select加matNativeControl：原生select没有mat-select那种监听选项列表变更的内部逻辑，就算ngFor重渲染选项也不会触发额外的变更检测
• 添加trackBy函数：trackBy会告诉Angular以你指定的唯一标识（这里是item.value）来判断列表项是否需要更新，哪怕priorities返回了新的数组引用，只要每个元素的value不变，Angular就不会销毁重建对应的mat-option节点，也就切断了死循环的触发条件。

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