React/Vue 列表渲染中 key 的作用是什么？｜阿里巴巴前端面经解析

60 秒回答模板

key 可以解释成同层节点的稳定身份标识。在 React、Vue 这类框架里，更新视图时不是简单按新旧数组位置逐个替换，而是通过 diff 或 reconciliation 比较新旧虚拟 DOM。key 可以帮助框架在同一个父节点下判断某个节点在更新前后是否还是同一个实体。如果 key 稳定，列表发生插入、删除、排序时，框架能更准确地复用已有 DOM 和组件实例，只移动必要节点，避免把 A 的状态、输入框内容或组件实例错误复用到 B 上。key 的要求是同层唯一、稳定、可预测，不要求全局唯一。通常应使用业务 id，而不是随机数，也尽量不要在会重排、插入、删除的列表里使用 index。特殊场景下，改变组件的 key 也可以主动让框架卸载旧实例并创建新实例，从而重置组件 state。

考点 身份识别本质

主线 同层唯一即可

易错点 把 key 理解成传给组件的普通 props，忽略它主…

深入解析

身份识别本质

key 不是给 DOM 使用的普通属性，而是给框架 diff 算法使用的身份标识。它的判断范围通常是同一个父节点下的兄弟节点集合。没有 key 或 key 不稳定时，框架更容易退化为按位置推断节点身份；一旦列表顺序变化，原来第一个位置的节点可能被当成新的第一个节点继续复用，导致数据和实例身份错位。准确理解 key 的前提，是把它看成这个节点是谁，而不是这个节点排第几个。

同层唯一即可

key 的唯一性要求发生在同一层级、同一组兄弟节点之间，而不是整个应用全局唯一。两个不同列表里都出现 key 为 1 通常没有问题，因为它们不在同一个比较集合中。真正有问题的是同一个数组渲染出的兄弟节点 key 重复，框架无法可靠判断应该复用哪一个旧节点。回答时要强调这个边界，否则容易把 key 误解成数据库主键那样的全局约束。

列表变更中的价值

当列表只在末尾追加时，即使用 index 作为 key，问题可能暂时不明显；但如果发生头部插入、中间删除、筛选、排序、拖拽重排，index 会随着位置变化而变化，身份就不稳定。稳定 key 能让框架知道某个业务项只是位置变了，而不是被另一个业务项替代。这样可以减少错误复用，也能让 DOM 移动、组件更新和副作用处理更接近真实业务变化。

组件实例与 state

key 会影响组件实例是否被复用。对于相同类型且 key 相同的组件，框架倾向于保留实例及其内部 state，只更新 props；如果 key 变化，通常会认为这是另一个组件实例，从而卸载旧实例并创建新实例。这会影响输入框值、局部展开状态、动画状态、未提交表单内容等。也因此，key 既能避免错误保留状态，也可以被有意识地用于重置状态。

错误 key 的后果

错误使用 key 不只是性能问题，更常见的是行为正确性问题。例如列表项里有输入框，使用 index 作为 key 后删除前面的元素，后面元素可能复用前一个位置的输入状态，用户看到的内容和实际数据不一致。随机 key 也很糟糕，因为每次渲染都会生成新身份，框架会频繁卸载和重建组件，既损失性能，也会丢失本该保留的 state。

与性能的关系

key 可以帮助 diff 更准确地定位旧节点和新节点的对应关系，从而减少不必要的创建、销毁和移动，但它不是性能优化的万能开关。key 写对了，框架更容易做正确复用；key 写错了，可能比不写还糟。真正的重点是身份语义要稳定，比如使用数据库 id、业务唯一编码等。只为了消除告警随便填 index 或随机值，往往掩盖了更深的状态错位风险。

易错点

把 key 理解成传给组件的普通 props，忽略它主要服务于框架的 diff 过程。
认为 key 必须全局唯一，实际只需要在同一父节点的兄弟节点中唯一。
为了消除告警随手使用 index，却没有判断列表是否会插入、删除、筛选或重排。
使用 Math.random 或时间戳作为 key，导致组件每次渲染都被重建并丢失状态。
只从性能角度解释 key，遗漏它对组件实例复用和 state 正确性的影响。

面试官追问

为什么不推荐在动态列表中使用 index 作为 key？

因为 index 描述的是位置，不是业务项身份。列表发生插入、删除、排序或筛选后，同一个业务项的 index 会变化，而同一个 index 又可能对应另一个业务项。框架按 index 复用实例时，容易把旧节点的 state、输入内容或副作用状态错误地复用到新数据上。

key 是否需要在整个页面全局唯一？

不需要。key 的比较范围主要是同一个父节点下的兄弟节点集合，也就是当前这组子节点 diff 的范围。不同父节点、不同列表中使用相同 key 通常没有问题。真正要避免的是同一组兄弟节点里 key 重复，否则框架无法可靠建立新旧节点映射。

为什么随机数不能作为 key？

随机数最大的问题是不稳定。每次渲染生成新的 key，框架会认为这些节点都变成了全新的节点，于是旧实例被卸载，新实例被创建。这样不仅增加渲染成本，还会丢失本应保留的组件 state、输入内容、焦点状态和生命周期连续性。

改变组件 key 能做什么？

改变 key 可以让框架把组件视为另一个实例，从而触发卸载旧组件并创建新组件。这常用于需要重置局部状态的场景，例如切换不同用户资料页时清空表单草稿，或让某个复杂组件重新初始化。但这应该是有意识的设计，而不是无意造成的副作用。

key 相同就一定不会更新 DOM 吗？

不是。key 相同只表示框架倾向于认为新旧节点是同一个实体，可以复用实例或 DOM 节点；但如果 props、文本、子节点或状态变化，仍然会执行必要更新。key 解决的是身份匹配问题，不是跳过所有更新的缓存机制。