为什么key一变组件就会重新挂载、状态全丢？

在 React、Vue 等现代声明式前端框架中，改变组件的 key 属性会导致该组件被立即执行彻底卸载（Unmount）并作为全新实例重新挂载（Mount），其内部保存在内存中的所有状态（如 React 的 useState、useRef 链表，Vue 的响应式状态及组件实例对象）也随之全数销毁并重置为初始值。这一现象的根本原因在于：key 在虚拟 DOM 协调算法（Reconciliation / Diff 算法）中并非普通传参，而是决定组件运行时身份唯一性（Identity）的核心凭证。当框架比对前后两棵虚拟 DOM 树时，只要发现同一层级中同位置节点的 key 发生变更，就会判定旧组件“已不复存在”，从而直接执行销毁与全新创建逻辑。

图 0：Key 作为运行时身份标识的生命周期分流机制

一、核心判定：Diff 算法如何界定“同一组件”？

为了理解为什么 key 一变状态就会丢失，首先需要明确现代前端框架（以 React 和 Vue 为代表）在协调（Reconciliation）阶段对“同一节点”的底层定义。

在不引入 key 的常规场景下，虚拟 DOM 引擎默认根据节点在层级树中的位置（Position）和元素类型（Type）来判断是否复用旧节点。例如，同层级的第一个子节点如果前后两次渲染都是 <UserProfile />，框架就会假设它们是同一个组件实例，仅仅向其传递新的 props 并执行更新生命周期。

然而，一旦显式声明了 key，key 的优先级就会跃升至与 type 平齐，甚至成为判定身份的第一准则。在框架内部比对机制中，判定“节点是否可以复用”必须同时满足两个硬性条件：

• 元素类型一致（Same Type）：例如前后都为同一个函数组件或同一个 HTML 标签（如 div）。
• 身份键一致（Same Key）：前后两次渲染输出的 key 严格相等（oldKey === newKey）。

只要 key 发生变更，即便组件类型完全一致、在父容器中的相对位置完全没有改变、传入的其他 props 哪怕完全一致，协调器也会判定：这是两个截然不同的组件实体。

图 1：协调算法复用判定逻辑矩阵

在 React 的单节点协调源码函数（reconcileSingleElement）中，有这样一段核心逻辑：

// React 协调源码片段概念简化
function reconcileSingleElement(returnFiber, currentFirstChild, element) {
  let child = currentFirstChild;
  while (child !== null) {
    // 首先校验 key 是否严格一致
    if (child.key === element.key) {
      // 其次校验 elementType 是否一致
      if (child.elementType === element.type) {
        // 唯有二者均满足，才复用现有 Fiber 节点
        deleteRemainingChildren(returnFiber, child.sibling);
        const existing = useFiber(child, element.props);
        return existing;
      }
      // key 相同但 type 不同，后续兄弟节点已无意义，全部删除
      deleteRemainingChildren(returnFiber, child);
      break;
    } else {
      // key 不匹配：当前旧 Fiber 节点不能复用，标记删除
      deleteChild(returnFiber, child);
    }
    child = child.sibling;
  }
  // 未找到可复用节点，创建全新 Fiber
  const created = createFiberFromElement(element, returnFiber.mode);
  return created;
}

在 Vue 3 的虚拟 DOM 比对逻辑中亦是如此，其 isSameVNodeType 函数开篇即判定：

// Vue 3 源码判定节点是否相同
export function isSameVNodeType(n1: VNode, n2: VNode): boolean {
  return n1.type === n2.type && n1.key === n2.key;
}

这意味着：key 并不协助当前组件“平滑更新”，而是直接定义“这是不是同一个实体”。一旦 key 变动，在协调器的视角里，旧组件被判定死亡，新组件被判定初生，没有任何继承状态的合法机制。

二、底层流水线：从 Key 变化到状态丢失的 5 个步骤

明确了比对规则后，我们进一步拆解：当协调器发现 key 发生变动后，内部究竟经历了怎样的物理清理与新建过程？为什么哪怕是在同一内存地址中运行的 JavaScript 代码，之前的状态也不能存留一丝一毫？

在 React 的 Fiber 架构下，组件内部的 useState、useReducer、useRef 并不是存放在函数体内部的局部变量，而是以单向链表（Hook LinkedList）的形式挂载在当前组件对应的 Fiber 节点（Fiber.memoizedState） 上。当 key 改变时，整个流水线执行过程如下：

图 2：从身份比对失败到内部状态全数释放的 5 个阶段

这 5 个关键步骤清晰揭示了为什么旧状态无法幸免：

1. 身份比对失配：父组件重新执行后产生新 VNode，协调器比对发现新旧 VNode 的 key 不同，判定无复用可能。
2. 加入删除队列：协调器把旧 Fiber 节点加入父节点的待删除队列（deletions 列表），并在 Commit 阶段前给该 Fiber 打上 Deletion 副作用标记。
3. 执行卸载副作用（Unmount）：在 Commit 阶段，框架遍历执行旧组件的清理钩子，如 React 的 useEffect 销毁函数（Cleanup function）、Class 组件的 componentWillUnmount，或 Vue 的 onUnmounted。
4. 移除 DOM 并清空引用：真实 DOM 节点从页面上直接移除；Fiber 树对旧节点的引用被彻底斩断，包含其上面挂载的所有 Hook 状态链表，随之被浏览器垃圾回收（GC）清空。
5. 挂载新组件（Mount）：协调器为新节点在内存中开辟全新 Fiber 空间，进入初始挂载阶段。此时组件函数被当做第一次运行，所有 useState(initialValue) 只会读取其传入的初始值参数，绝不可能读取到已销毁实例的历史状态。

三、警惕四种无意识的“误改 key”反模式

在日常开发中，很少有人会故意写出破坏体验的代码。更多时候，“状态全丢、输入框失去焦点、输入内容被强制刷掉”往往是因为无意识地让 key 变成了不稳定值。以下是最典型的四类反模式：

图 3：四类典型反模式及其导致状态异常的机制剖析

1. 动态生成 key（如随机数与时间戳）

最致命的操作就是在 JSX 中写入 key={Math.random()} 或 key={Date.now()}。这不仅毫无优化作用，而且每次父组件重绘，该组件都将接收到一个全新的 key，进而触发连环销毁-重建。在有输入框、滚动条或内部动画的表单组件中，用户往往刚键入一个字母，输入框的焦点就立刻脱焦，刚输入的内容瞬间消失。

2. 将易变业务状态与 key 强绑定

有时开发者为了“确保数据刷新”，会将数据状态拼接到 key 中，例如 key={`${item.id}_${item.status}`}。如果 item.status 会随着用户点击标签而频繁变迁，那么每次变迁都会让整个卡片经历一次卸载和重建。如果该卡片内有未保存的备忘笔记、展开收起状态，这些状态都将彻底归零。

3. 在组件函数内部声明子组件

很多初学者喜欢在父组件内部写内部子组件函数：

function ParentPage() {
  const [count, setCount] = useState(0);

  // 错误写法：每次 ParentPage 渲染都会在内存中创建一个新的 SubForm 函数对象
  function SubForm() {
    const [text, setText] = useState('');
    return <input value={text} onChange={e => setText(e.target.value)} />;
  }

  return (
    <div>
      <button onClick={() => setCount(c => c + 1)}>Count: {count}</button>
      <SubForm key="fixed-key" />
    </div>
  );
}

即使给 <SubForm /> 指定了固定的 key="fixed-key"，只要点击按钮更新了 count，输入框内的文字仍然会瞬间消失。这是因为 SubForm 是在函数体内定义的，每次渲染都生成了一个全新的函数引用，协调器判定 element.type 改变，同样会直接销毁旧组件并重新挂载。

四、反向利用：用 Key 优雅重置组件状态

虽然 key 变更导致状态丢失经常成为“偶发 Bug”的温床，但在明确了解这一机制后，它也是前端架构中最纯粹、最优雅的状态重置模式之一。

在没有 key 重置方案之前，如果我们要在用户切换不同数据记录时清空表单（例如后台管理系统中的“编辑客户资料”抽屉），通常需要编写大量繁琐且脆弱的 useEffect 或监听逻辑：

// 传统繁琐做法：在子组件内部被动监听并逐一手动重置每一个状态
function ProfileEditor({ userId }) {
  const [draftName, setDraftName] = useState('');
  const [draftBio, setDraftBio] = useState('');
  const [activeTab, setActiveTab] = useState('basic');

  useEffect(() => {
    // 监听 userId 变更，逐一手工重置
    setDraftName('');
    setDraftBio('');
    setActiveTab('basic');
  }, [userId]);

  return <form>...</form>;
}

这种手动监听的做法存在诸多弊端：首先需要维护繁杂的初始值常量；其次，如果表单中使用了非受控组件（如第三方富文本编辑器、上传文件控件、DOM 滚动位置），仅仅靠 useEffect 修改 React 状态很难彻底清理第三方库在底层 DOM 上留下的脏数据。

推荐的工程解法：直接在父级指定业务 ID 作为 key：

// 现代工程模式：通过 key 明确组件的业务实体归属
function ProfileDrawer({ currentUserId }) {
  // 当 currentUserId 从 101 变成 102 时，旧编辑器被彻底销毁，新编辑器自动从零挂载
  return <ProfileEditor key={currentUserId} userId={currentUserId} />;
}

五、总结：Key 的使用决策指南

为便于在实际开发与代码评审中快速做正确决策，以下将核心依据汇总为决策路径与对照清单：

图 4：Key 的行为决策路径与核心开发铁律

综上所述，key 的本质不是优化参数，而是组件的虚拟身份身份证。理解了虚拟 DOM Diff 算法中 type + key 的双重校验机制，不仅能彻底搞清楚为什么 key 一变状态就会全丢，更能将这一特性化为己用，写出结构更干净、状态更可控的高质量前端代码。