key 是虚拟 dom 节点的唯一身份凭证，决定 diff 时是否复用节点：仅类型与 key 均相同时才复用；用 index 作 key 会导致状态错乱、动画异常；应选用稳定唯一业务标识（如 id）而非临时值。
Key 是虚拟 DOM 节点的唯一身份凭证，不是可有可无的“装饰”，而是 Diff 算法判断“这个节点要不要复用”的决定性依据。
Key 决定节点是否被复用
当数据变化触发重新渲染时，框架会生成新虚拟 DOM，并与旧虚拟 DOM 逐层比对。比对逻辑是：先看节点类型，再看 key 值。只有类型相同 且 key 相同，才认为是同一个节点，进而只更新属性、文本或子节点；否则一律当作全新节点处理——销毁旧实例，创建新实例。
比如一个列表从 ['a', 'b', 'c'] 变为 ['b', 'c', 'd']：
- 没 key 或 key 用 index：原第 0 位 'a' 和新第 0 位 'b' key 都是 0 → Vue/React 认为这是同一节点，仅把文本从 'a' 改成 'b'；后续所有项都发生类似“错位 patch”，最终导致状态错乱（如输入框内容错位、动画中断）
- 有稳定 key（如 item.id）：'b' 和 'c' 的 key 未变，对应节点被精准复用；'a' 因 key 消失被卸载；'d' 因新 key 出现被挂载 —— 行为符合直觉，状态得以保留
Key 影响组件生命周期与内部状态
带状态的组件（如含 input、计时器、展开收起逻辑）依赖 key 的稳定性来维持实例。key 改变，等于告诉框架：“这是另一个东西”，旧组件会走完整卸载流程（beforeUnmount / componentWillUnmount），新组件从头初始化。
典型应用场景：
- 强制重置表单：给表单组件绑定
:key="formVersion"，每次修改formVersion（如 +1 或时间戳），组件就重建，input 清空、校验重置 - 切换不同数据源的同构组件：用不同 id 作 key，避免缓存残留（如用户 A 的详情页和用户 B 的详情页共用同一组件，但 key 不同，互不干扰）
为什么不能用 index 当 key？
数组索引不具备稳定性。一旦插入、删除或排序，index 就整体偏移。框架无法区分“位置变了”和“内容变了”，只能按顺序硬套，造成：
- 动画异常：元素看起来“跳来跳去”，实际是旧节点被错误复用
- 表单失焦或值错乱：用户在第 2 个输入框打字，插入一项后，原本第 2 个输入框变成第 3 个，但焦点和 value 却被错误地“继承”到新位置
- 性能浪费：本可复用的节点因 key 变了被销毁重建，尤其在长列表中明显
写 key 的实用原则
真正有效的 key 必须满足两个硬性条件：
- 在同一列表内唯一：不能出现重复值，哪怕只差一个字符也不行
-
与业务数据强绑定、长期稳定：优先选后端返回的 id、uuid、唯一 slug；没有则考虑组合字段（如
item.type + '-' + item.timestamp），但要确保组合结果不重复、不变 - 避免临时值：不用
Math.random()、Date.now()（除非明确要强制刷新）、不基于易变状态生成
