Angular中使用*ngFor绑定对象数组到输入框的双向绑定稳定性问题

嘿，这个问题问到点子上了！咱们结合实际项目场景来唠唠：

首先，先给你吃个定心丸：如果你的dogs数组只是简单的静态数组，或者只会做末尾新增/删除元素、修改对象内部属性（比如直接改dog.name）这类操作，你现在写的代码完全可以正常工作，不会有什么麻烦。因为Angular的*ngFor默认会用对象的引用作为“跟踪标识”，只要每个dog对象的引用没变化，Angular就能精准识别每个列表项，不会搞混输入框的绑定关系。

但！一旦你的数组操作涉及以下场景，当前代码就可能出问题：

• 对数组执行排序、筛选、在中间位置插入/删除元素的操作
• 每次更新数组时，都是生成新的对象引用（比如用扩展运算符...创建新对象、用map返回全新对象，而不是修改原对象的属性）

出现的具体问题通常是：

• 输入框的焦点突然丢失，比如你刚在某个输入框打字，数组一更新，焦点直接跳走了
• Angular会销毁旧的DOM元素再重新创建，带来不必要的性能损耗，数组元素多的时候更明显
• 极端情况下，输入框的绑定值会出现错乱，比如你修改第一个元素的name，结果第二个元素的输入框跟着变了

那这时候该怎么办？这就轮到trackBy出场了——它能告诉Angular用什么标准来识别唯一的列表项，而不是默认的对象引用。这里要注意：用对象的唯一标识（比如dog.id）是最优选择，比用index更好，因为index会随着数组元素的增删改序而变化，稳定性不如固定的唯一ID。

给你举个实用的例子：

1. 先在组件类里定义trackBy函数：

// 假设你的Dog类型有唯一的id属性
trackDogById(index: number, dog: Dog): number {
  return dog.id;
}

2. 然后在模板里关联这个函数：

<div *ngFor="let dog of dogs; trackBy: trackDogById">
  <input [(ngModel)]="dog.name" />
</div>

如果你的dog对象没有唯一ID属性，那退而求其次可以用index作为跟踪标识，但要注意：如果数组有排序、中间增删元素的操作，index对应的元素会变化，还是可能有小问题，这时候尽量给对象加个唯一标识会更稳妥。

总结一下：你的初始代码在简单场景下没问题，但从代码健壮性和性能优化的角度来说，给*ngFor加上合适的trackBy是最佳实践，能避免后续数组操作带来的各种奇怪问题。

内容来源于stack exchange