为何此场景下用数组索引作React key时重渲染性能更优？

核心原因很直接：DOM节点移动的开销远大于文本内容更新的开销，这就是你看到测试结果和预期相反的关键。

两种key的实际执行逻辑 #

以索引为key的真实行为 #

你原本以为React会执行10000次更新+1次插入，但实际过程完全不同：

• 新旧列表的key对应关系是：旧列表key为0~9999，新列表key为0~10000。React会认为每个索引对应的<li>节点是同一个（因为key一致）。
• 所以React只做两个操作：
  1. 遍历每个<li>，修改其文本内容（比如原索引0的<li>从0改成-1，索引1的从1改成0，以此类推）——这只是修改DOM节点的textContent，属于轻量操作，速度极快。
  2. 在列表末尾新增一个<li>显示9999——一次简单的DOM插入。

以唯一值为key的真实行为 #

你的理解有误，React并不会只插入新元素：

• 旧列表的key集合是[0,1,...,9999]，新列表是[-1,0,1,...,9999]。React会识别到：
  • -1是新增的key，需要创建新的<li>节点。
  • 原有0~9999这些key全部存在，但它们在列表中的位置整体向后偏移了一位。
• 这时候React需要把原来的10000个<li>节点逐个移动到下一个位置，再将新创建的<li>插入到头部。
• DOM节点的移动操作涉及浏览器重新计算布局、重绘，大量节点的移动开销远高于修改文本内容，这就是你看到明显延迟的原因。

补充说明 #

React官方不推荐使用索引作为key，是因为在元素排序、删除中间元素这类场景下，会导致组件内部状态错位（比如列表项中的输入框内容混乱）。但在你这种「仅头部插入、列表项无内部状态」的极端场景中，索引key反而因为避免了DOM移动，获得了更好的性能。

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