React 的 key 有什么作用？为什么不建议随便用数组下标？

知识点详解：列表变了以后，状态应该跟着谁走

先把输入框和业务项目分开看

假设列表有 A、B、C 三个用户，每一行组件内部保存一份尚未提交的备注。你在 B 行输入文字，然后删除 A。

如果用下标作为 key，旧的0号组件原来代表 A，现在代表 B；旧的1号组件原来代表 B，现在代表 C。React 看到同一位置、同一类型、同一 key 的组件，有理由继续保留它的内部状态。

结果不是浏览器把字搬错了，而是咱们告诉 React“它还是原来的组件”，但业务对象已经换人了。受控输入、无内部状态等实现可能不会出现同一种表现，却不能证明下标代表业务身份。

稳定 ID 让身份跟着数据，而不是位置

把 A、B、C 的稳定 ID 用作 key，删除 A 后，B 与 C 的组件可以继续对应自己的身份。它们的位置改变，但不需要假装成原来的0号和1号项目。

key 只要求在相应兄弟集合中合适地区分身份，并不是全站必须唯一。它也不是普通 prop，子组件需要业务 ID 时，应另传 id。

不要在每次渲染时调用随机数生成 key。每轮都换身份会导致反复重建，输入、焦点和局部状态可能丢失。临时数据可以在创建数据时分配稳定标识，关键是它在后续渲染中保持一致。

什么时候可以有意换 key？

假设一个聊天编辑框先给用户 A 写消息，再切到用户 B。业务要求切换对象就清空草稿，可以用接收人的稳定 ID 作为编辑框 key，让身份变化对应一次重置。

这并不意味着所有切换都应该丢状态。有的产品希望不同对象分别保留草稿，就需要把草稿存到适合的位置，并按业务 ID 管理。

因此，换 key 是一个生命周期决定：你是要继续原组件，还是建立新的组件。不要为了“刷新页面”随便改 key，然后再修补焦点和用户输入丢失。

key 正确了，也不等于没有渲染工作

父组件更新时，子组件仍可能参与渲染。key 解决身份对应，不负责替代 memo、状态归属和订阅优化。

验证列表时，至少检查插入首项、删除中间项、排序和过滤，尤其观察输入值、勾选状态、展开状态和焦点。静态列表看不出身份错误，真正的考点在列表发生变化以后。

如果列表从不重排、增删，项目也没有需要保留的局部状态，用下标有时可以接受。但需要把这些限制说清楚，而不是把它当成默认选项。

本题机制参考：React：Preserving and Resetting State。

面试官继续追问

key 必须是数据库主键吗？

不必须，但应稳定且能在相应兄弟集合中区分业务身份。可以使用数据创建时分配的可靠 ID。

key 相同，组件类型不同，会保留状态吗？

不能只靠相同 key 保证。组件类型和树位置等也参与身份判断，换成不同类型通常会重置对应状态。

为什么子组件 props.key 是 undefined？

key 是 React 使用的特殊标记，不作为普通 prop 传入。需要这个值时另传业务字段。

面试速记卡

• key：表示相应兄弟集合中的身份。
• 状态复用：身份对应正确，局部状态才跟着正确的数据。
• 下标：代表位置，重排后未必代表同一项目。
• 随机 key：每次变身份，可能反复重置状态和焦点。
• 改变 key：可以主动重置，但要符合业务生命周期。