如果将列表的index设置为key会有什么问题？｜阿里巴巴前端面经解析

60 秒回答模板

key 的作用是帮助框架在列表 diff 时识别每一项的稳定身份，而 index 只是当前渲染顺序下的位置，不是数据本身的身份。如果列表永远不变，index 勉强可以工作；但一旦有插入、删除、排序、过滤，后续元素的 index 会整体变化，框架会认为原来同一位置的组件还是同一个，从而复用错误的组件实例和 DOM。结果可能是输入框内容跑到别的行、展开状态错位、动画进入退出异常、异步请求或缓存命中错误、useEffect 清理和订阅对象不对应。更好的做法是使用业务上稳定且唯一的 id，例如数据库 id、商品 id、消息 id。只有在纯静态列表、不会重排、不会增删、列表项没有内部状态且不会承载复杂副作用时，index 才可以作为退而求其次的 key。

考点 key 的本质是数据身份

主线 位置变化会制造身份错位

易错点 只回答会影响性能，却没有说明组件实例和数据身份错位才是…

深入解析

key 的本质是数据身份

key 不是给开发者看的序号，也不是单纯为了消除控制台警告。它是框架在列表 diff 过程中判断旧节点和新节点是否代表同一条数据的身份标识。一个好的 key 应该满足稳定、唯一、和业务数据绑定这三个条件。稳定意味着同一条数据在多次渲染中 key 不变，唯一意味着同一层级列表里不会重复，和数据绑定意味着 key 跟记录本身相关，而不是跟它当前排在第几位相关。index 恰好只满足短期唯一，却不满足数据身份稳定。

位置变化会制造身份错位

当列表发生插入、删除、排序或过滤时，很多元素的数据没有变，但它们的 index 会变。比如在列表头部插入一项，原来 index 为 0 的数据变成 index 为 1，原来 index 为 1 的数据变成 index 为 2。框架用 index 作为 key 时，会把新位置上的数据和旧位置上的组件实例对应起来，等于把这个位置的组件当成了这条数据的组件。这会让节点身份跟数据身份错位，表面上 DOM 被复用了，实际复用到了错误对象上。

组件 state 会被错误继承

列表项如果只是展示纯文本，问题可能暂时不明显；但一旦列表项组件内部有 state，index key 的风险就会暴露。常见例子包括某一行是否展开、复选框是否选中、输入框当前值、正在编辑的临时草稿、悬浮状态、校验错误等。删除前面一项后，后面的组件实例可能被保留下来并绑定到新的数据上，于是 A 数据的编辑状态会落到 B 数据身上。用户看到的是某一行突然继承了另一行的状态，这类 bug 通常很隐蔽。

DOM 与非受控输入也会受影响

使用 index 作为 key 时，框架倾向于复用相同位置的 DOM 节点。对于非受控 input、textarea、select，真实值可能保存在 DOM 内部，而不是完全由数据驱动。列表重排后，DOM 节点虽然还在原位置，但对应的数据已经换了，用户输入的内容可能显示在错误的列表项上。即使使用受控组件，也可能因为组件实例、光标位置、组合输入状态或校验提示被复用，产生体验层面的错乱。

动画、缓存和副作用会错复用

index key 的问题不只影响表单。列表项如果有进入退出动画，错误的 key 会让框架误判哪个元素新增、哪个元素移除，导致动画对象不对。列表项如果有 memo 缓存、虚拟列表缓存、图片加载状态或昂贵计算结果，缓存可能命中到另一条数据。更严重的是副作用场景，例如列表项内部订阅某个 id、发起异步请求、绑定定时器或注册事件监听，组件身份错位后，清理和重新绑定的时机可能不符合真实数据变化，造成旧数据残留或订阅对象错误。

可以勉强使用的场景

index 不是绝对不能用，而是适用范围很窄。它只适合列表内容完全静态、顺序永远不变、不会插入删除过滤排序、列表项没有内部 state、没有非受控表单、没有动画、没有副作用、也不依赖缓存的场景。比如写死的导航文案、固定数量的说明条目、不会由用户操作改变的静态展示列表，index 的风险较低。但只要未来有交互扩展的可能，仍然应该优先补充稳定 id，避免后续需求变化时埋下状态错位问题。

易错点

只回答会影响性能，却没有说明组件实例和数据身份错位才是核心风险。
认为加了 key 就一定正确，忽略 index key 只绑定位置而不是绑定业务数据。
把所有场景都说成绝对不能用，没有说明完全静态列表中可以勉强使用。
推荐使用随机数或每次渲染生成的新值作为 key，反而导致频繁卸载和重建。
只提 DOM diff，不提输入框值、组件 state、动画、缓存和副作用的错误复用。

面试官追问

为什么不写 key 会有警告，而写 index 仍然可能有问题？

不写 key 时，框架缺少列表项身份信息，所以会提示开发者补充。写 index 虽然给了一个 key，但这个 key 只稳定绑定到位置，不稳定绑定到数据。警告消失不代表语义正确，只代表框架拿到了一个可用于 diff 的标识。

index 作为 key 一定会导致页面渲染错误吗？

不一定。如果列表完全静态、顺序不变、没有内部状态和副作用，index 通常不会表现出问题。但在真实业务中，列表经常会搜索、排序、插入、删除或编辑，因此 index key 的风险会随着交互复杂度明显上升。

为什么输入框内容会跑到另一行？

因为输入框的 DOM 节点或组件实例可能被复用在同一个位置，而列表数据已经因为删除、插入或过滤发生了位移。框架认为这个 key 对应的还是旧实例，于是旧输入状态被保留下来，却显示在新的数据行上。

如果后端没有 id，应该怎么生成 key？

优先从业务字段组合出稳定唯一值，例如类型加创建时间加业务编号，前提是组合后不会重复且不会随渲染变化。如果数据是前端创建的，可以在创建数据时生成一次本地 id 并保存到数据对象里，不要在 render 阶段临时生成随机 key。

使用随机数作为 key 能解决 index 的问题吗？

不能。随机 key 虽然避免了位置错位，但每次渲染都会变化，框架会认为所有列表项都是新节点，导致组件反复卸载和重建。本地 state 会丢失，性能也会变差，副作用还可能频繁清理和重新执行。