第 12 卷

若不绑定key，Vue会采用“就地复用”策略（默认使用节点索引作为隐式key），该策略在列表更新时易出现节点状态混乱、性能低下等问题。绑定key的核心价值的体现在以下2个场景：

1. 避免节点状态混乱，保证渲染正确性：

示例：列表项包含表单输入框，无key时删除中间项导致输入状态错乱。

• 无key场景：删除列表第2项时，Vue会“就地复用”第3项的节点（因为索引从2变为1），导致第

3项输入框的内容被保留到第2项的位置，状态混乱；

• 有key场景：每个列表项绑定唯一key（如数据id），删除第2项时，diff算法通过key识别出第3项

是独立节点，仅销毁第2项节点，第3项节点及其输入状态被完整保留，渲染正确。

1. 优化列表更新性能，减少DOM操作：

当列表发生重排（如排序、插入、删除）时，key可帮助diff算法精准复用已有节点，减少销毁/创建操作。例如，在列表头部插入新项：

• 无key场景：Vue会认为所有节点的索引都发生了变化，销毁原有所有节点，重新创建新的列表节

点，DOM操作开销大；

• 有key场景：diff算法通过key识别出原有节点的key均存在，仅需创建新项节点并插入到头部，原

有节点全部复用，大幅减少DOM操作，提升性能。

补充：key的取值需满足“唯一性”和“稳定性”（即节点对应的key不会随位置变化而改变），通常推荐使用数据的唯一ID（如后端返回的id）作为key。

1. 为什么不建议在Vue中使用index作为key？

虽然Vue支持使用index（列表索引）作为key，但在列表发生插入、删除、排序等操作时，会导致key 失去“唯一性”和“稳定性”，进而引发节点状态混乱、性能下降等问题，因此不建议使用。具体原

因如下：

1. 破坏key的稳定性，导致节点状态混乱：

index是节点的位置索引，当列表发生插入、删除、排序时，节点的index会随之变化，导致同一节点的key在新旧VNode树中不一致。diff算法会误判为“旧节点已删除、新节点需创建”，但实际节

点内容可能未变，进而导致节点状态（如表单输入值、组件内部状态）丢失或错乱。

示例：列表排序后，原索引为2的节点排序后索引变为0，key从2变为0。diff算法认为这是一个新节点，会销毁原节点（丢失内部状态），创建新节点，导致状态混乱。

1. 失去性能优化意义，甚至降低性能：

使用key的核心目的是复用节点、减少DOM操作。但index作为key时，列表重排会导致大量节点的 key发生变化，diff算法无法复用原有节点，只能销毁旧节点、创建新节点，与“就地复用”策略无

差异，甚至因额外的key对比开销降低性能。

例如，在列表头部插入新项时，所有原有节点的index都会+1，key全部变化，diff算法会销毁所有

key会为后续开发埋下隐患，增加调试成本。

推荐替代方案

优先使用数据本身的“唯一标识”作为key，如：

• 后端返回的数据：使用数据的id字段（如 v-for="item in list" :key="item.id"）；
• 前端生成的临时数据：使用UUID、时间戳+随机数等生成唯一标识；
• 无唯一ID的简单列表：若列表无状态（如纯文本列表）且无增删排序操作，可临时使用index，但需

注明场景限制。

（注：文档部分内容可能由 AI 生成）