React Reconciliation 单节点 Diff 算法

大家好，我是你们的“React 熟手”，也是你们心目中的那个“把代码写得像诗一样”的专家。今天我们不聊什么高深莫测的架构设计，也不谈什么微前端治理，我们来聊聊 React 的“心脏”跳动时，它脑子里在想什么——具体来说，就是当它决定“我要更新这个 DOM 节点了”的时候，它怎么决定是“换个新发型”，还是“把旧衣服改一改”。

这玩意儿，在 React 官方文档里有个很学术的名字，叫 Reconciliation，也就是我们常说的“协调”。而今天我们要聚焦的，是协调算法中最基本、最核心、也是最容易被大家忽视的一个环节——单节点 Diff 算法。

想象一下，你的浏览器就是一个巨大的衣柜，你的 React 应用就是那个衣柜的主人。每当你的状态（State）发生改变，或者父组件重新渲染时，React 就会拿着一份“新衣服清单”（Virtual DOM）来到你的衣柜前，试图把“旧衣服”变成“新衣服”。

这个过程如果不加控制，那就是灾难。你可能会把所有旧衣服都扔了，再买一堆新的。那太浪费了，而且用户体验极差，页面会闪一下，闪烁意味着重排和重绘，意味着卡顿，意味着你的用户会翻白眼。

所以，React 的单节点 Diff 算法，本质上就是一个极其精明的“旧物改造工程师”。它的目标只有一个：在尽量不破坏现有 DOM 结构的前提下，通过最小的改动让界面达到新的状态。

好了，废话不多说，我们直接进入正题。为了让你彻底搞懂这个算法，我准备了一个非常接地气的类比，以及一大堆代码示例。

第一部分：协调的哲学——“垃圾桶”理论

在深入代码之前，我们需要先建立一个核心的世界观。React 的协调算法，尤其是单节点层面，遵循着一个残酷但高效的逻辑：如果类型变了，旧的元素就死了，它进了垃圾桶。

这听起来有点无情，但这是性能的保障。

假设你有一个列表，里面有三条数据：

1. A
2. B
3. C

你的 UI 展示的就是 [A, B, C]。

现在，你的状态变了，你想要 [B, C, A]。

React 会怎么处理？
它会从头开始比对。

1. A vs B：React 拿着新列表的第一个元素 B，去旧列表里找。哦，B 在旧列表里存在！但是，React 先看的是类型。B 的类型是“文本节点”，和 A 一样。所以，React 觉得：“既然类型一样，那就别扔了，先留着，看看后面是不是有更合适的。”
2. B vs C：现在比对第二个。新列表的 B 和旧列表的 B 类型一样。React 继续：“也留着。”
3. C vs A：现在比对第三个。新列表的 A 和旧列表的 C 类型一样。React 继续：“也留着。”

等等，这不对啊！我们想要的是 [B, C, A]，但我怎么把 A 放在最后了？而且 B 和 C 也不应该留在原来的位置上。

这时候，React 的单节点 Diff 算法就要开始它的“大手术”了。它发现，虽然类型没变，但是顺序变了。于是，React 会把原来位置上的 B 和 C 从 DOM 里移除，放到最后，然后把新来的 A 放在前面。

这就是单节点 Diff 的核心：类型不匹配，销毁重建；类型匹配，尝试复用。

第二部分：黄金法则——Type 和 Key

现在，让我们把镜头拉近，看看 React 是如何判定一个节点是否匹配的。这主要看两个指标：type 和 key。

1. Type（身份证号）

type 是 React 元素的第一个参数。对于原生 HTML 元素，它是字符串 'div'、'span'；对于组件，它是组件函数本身。

这是 React 判定“是否是同一个人”的唯一硬性标准。

代码示例 1：类型不匹配，直接销毁

// 旧节点
const oldVNode = {
  type: 'div',
  props: { className: 'box' },
  children: []
};

// 新节点
const newVNode = {
  type: 'span', // 类型变了！从 div 变成了 span
  props: { className: 'box' },
  children: []
};

// React 的 Diff 逻辑（伪代码）
function reconcile(oldNode, newNode) {
  if (oldNode.type !== newNode.type) {
    // 哎呀，类型不一样，这老兄弟没法用了。
    // 直接在 DOM 里把旧的删掉，然后新建一个 span。
    return createNewNode(newNode);
  }

  // 如果类型一样，那就继续往下看 props 和 key
  return oldNode; // 或者是复用节点并更新 props
}

2. Key（名字标签）

如果 type 相同，React 就会进入“复用模式”。这时候，key 就登场了。key 是 React 元素的 props 里的一个特殊属性。

key 的作用是什么呢？它的作用是唯一标识。

还记得刚才那个 [A, B, C] 变成 [B, C, A] 的例子吗？如果我们没有 key，React 会认为只要类型一样（都是文本节点），就可以随便放。那样的话，React 就会傻傻地不动，或者搞出一些奇怪的位置移动。

但是，如果给了 key 呢？

// 旧列表
[
  { type: 'div', key: 'a', content: 'A' },
  { type: 'div', key: 'b', content: 'B' },
  { type: 'div', key: 'c', content: 'C' }
]

// 新列表
[
  { type: 'div', key: 'b', content: 'B' }, // key 是 b
  { type: 'div', key: 'c', content: 'C' }, // key 是 c
  { type: 'div', key: 'a', content: 'A' }  // key 是 a
]

现在 React 进行单节点 Diff：

1. 第一轮：旧 key='a' vs 新 key='b'。类型一样，但 key 不一样。React：“哦，这不是我要找的那个 a，a 去哪了？算了，先不管，看看下一个。”
2. 第二轮：旧 key='b' vs 新 key='b'。类型一样，key 一样！React：“找到了！这个 b 是我的老朋友，它没死，只是位置变了。好，我把它从原来的位置拿走，放到现在的位置上。”
3. 第三轮：旧 key='c' vs 新 key='c'。同理，复用。
4. 第四轮：旧列表空了，新列表还有一个 key='a'。React：“a 没找到旧版本，这是一个新来的，创建一个新的 DOM 节点，插进去。”

结论： key 是 React 能够精准定位节点的 GPS。

第三部分：Props Diff——细节决定成败

当一个节点通过 type 和 key 的双重认证，确认为“同一个人”后，React 接下来要做的就是更新这个人的外貌，也就是 props。

React 使用一个叫做 Object.is 的算法来比较 props。这比简单的 === 要强一点，因为它能正确处理 0 和 -0，以及 NaN 和 NaN（它们在 JS 里虽然 === 不等，但在语义上是一样的）。

但是，这里有一个巨大的坑，一个让无数初级开发者掉进去的坑：事件处理器。

代码示例 2：箭头函数的陷阱

// 这是一个糟糕的写法
function Counter() {
  const [count, setCount] = useState(0);

  // 注意！每次 render 都会创建一个新的函数
  const handleClick = () => {
    console.log('Clicked!');
    setCount(count + 1);
  };

  return (
    <button onClick={handleClick}>
      Count is {count}
    </button>
  );
}

让我们模拟一下 React 的 Diff 逻辑：

1. 第一次渲染：

   • 旧 VNode：{ type: 'button', props: { onClick: [Function] } }
   • 新 VNode：{ type: 'button', props: { onClick: [Function] } }
   • React 比较：type 是 'button'，匹配！key 不存在，匹配！
   • React 比较 props：onClick。它拿新函数和旧函数比较。因为是两个不同的函数实例（内存地址不同），Object.is 返回 false。
   • 结果：React 认为 onClick 属性变了。它把旧的 DOM 节点销毁，创建一个新的 DOM 节点，并把新函数挂上去。

2. 第二次渲染：

   • 同样的事情再次发生。旧的函数被扔进垃圾桶，新的函数被请进来。
   • 结果：虽然 type 和 key 没变，但因为 onClick 这个 prop 每次都不一样，React 以为你换了一个按钮。

这就是为什么有时候你会觉得 React 性能很差，明明只是改了个数字，怎么整个 <button> 都被重绘了？ 就是因为那个该死的箭头函数。

解决方案： 把 handleClick 提取到组件外部，或者用 useCallback 包裹。

// 好的写法
const handleClick = useCallback(() => {
  setCount(count + 1);
}, [count]); // 依赖项是 count，只有 count 变了，函数才变

// 或者更彻底的写法
const handleClick = () => {
  setCount(c => c + 1); // 使用函数式更新，依赖项数组为空
};

除了事件处理器，还有两个特殊的 props 需要特别注意：

1. children：React 对 children 的处理非常特殊。它不会直接比较 children 对象，而是会遍历 children 进行递归 Diff。这是为了处理 Fragment 和 Text 节点。
2. key：key 也是一个 prop，但它有特殊待遇。React 在 Diff 时，会优先检查 key。如果 key 不同，React 会认为这是一个完全不同的节点，直接销毁重建，而不会去管它的 type 是否相同。

第四部分：深入单节点 Diff 的代码实现

好了，理论讲完了，让我们来点硬核的。我会写一个简化版的 reconcileNode 函数，模拟 React 在处理单个节点时的心理活动。

这个函数接收四个参数：

• oldVNode: 旧节点的虚拟 DOM
• newVNode: 新节点的虚拟 DOM
• parentDOM: 父容器 DOM
• index: 当前节点的索引（用于插入）

/**
 * 简易版单节点 Diff 算法
 */
function reconcileNode(oldVNode, newVNode, parentDOM, index) {
  // 1. 类型检查：这是第一步，也是最残酷的一步
  if (typeof oldVNode.type !== typeof newVNode.type) {
    // 类型都不一样了，比如从 div 变成了 span，那肯定是彻底分手
    // 删除旧的，创建新的
    const newDOM = createDOM(newVNode);
    parentDOM.replaceChild(newDOM, oldVNode.dom);
    return newDOM;
  }

  // 2. 类型相同，进入“复用”模式
  // 检查 key：这是定位的关键
  if (oldVNode.key !== newVNode.key) {
    // key 不一样，说明这是两个不同的人，虽然长得一样（类型一样）
    // 比如旧列表里的 'A' 被删了，新列表里来了个 'D'，虽然都是 div
    // React 会认为这是一个新元素，直接销毁旧的，创建新的
    const newDOM = createDOM(newVNode);
    parentDOM.replaceChild(newDOM, oldVNode.dom);
    return newDOM;
  }

  // 3. 类型和 key 都匹配，恭喜你，这是同一个节点！
  // 我们可以复用 DOM 节点，只需要更新 props

  // 更新 props
  updateProps(oldVNode, newVNode);

  // 更新 children（递归处理子节点）
  reconcileChildren(oldVNode, newVNode, oldVNode.dom);

  // 返回 DOM 引用（方便父节点使用）
  return oldVNode.dom;
}

// 辅助函数：创建 DOM
function createDOM(vNode) {
  if (vNode.type === 'text') {
    const dom = document.createTextNode(vNode.props.text);
    return dom;
  }

  const dom = document.createElement(vNode.type);

  // 设置属性
  for (const key in vNode.props) {
    if (key === 'children') continue; // children 单独处理
    if (key === 'style') {
      // 简单的样式处理
      dom.style.cssText = vNode.props[key];
    } else {
      dom.setAttribute(key, vNode.props[key]);
    }
  }

  // 挂载到 DOM
  if (vNode.dom) {
    // 如果已经有 dom，说明是更新，React 会处理插入位置
    // 这里简化处理，直接插入到父节点
    if (vNode.parent) {
      vNode.parent.appendChild(dom);
    }
  } else {
    // 如果是新节点，直接挂载
    vNode.dom = dom;
  }

  return dom;
}

// 辅助函数：更新属性
function updateProps(oldNode, newNode) {
  const oldProps = oldNode.props;
  const newProps = newNode.props;

  // 遍历新属性
  for (const key in newProps) {
    // 如果属性变了，就更新 DOM
    if (oldProps[key] !== newProps[key]) {
      if (key === 'style') {
        oldNode.dom.style.cssText = newProps[key];
      } else if (key === 'className') {
        oldNode.dom.setAttribute('class', newProps[key]);
      } else if (key === 'value' || key === 'checked') {
        // 对于表单元素，直接赋值
        oldNode.dom[key] = newProps[key];
      } else if (key.startsWith('on')) {
        // 事件监听器
        // 注意：这里为了简化，直接覆盖。实际 React 会做很多优化
        oldNode.dom[key] = newProps[key];
      } else {
        oldNode.dom.setAttribute(key, newProps[key]);
      }
    }
  }

  // 遍历旧属性，看看有没有被删掉的
  for (const key in oldProps) {
    if (!(key in newProps)) {
      // 属性被删除了
      if (key === 'style') {
        oldNode.dom.style.cssText = '';
      } else {
        oldNode.dom.removeAttribute(key);
      }
    }
  }
}

看懂了吗？这就是单节点 Diff 的全部逻辑。它非常简单，简单到有点枯燥。但正是这种简单，保证了 React 的核心性能。

第五部分：为什么说单节点 Diff 是“上帝视角”？

很多同学会问：“老师，React 的 Diff 算法不是还有双端比较、最长递增子序列吗？你只讲了单节点，是不是太浅了？”

这你就不懂了。单节点 Diff 是整个 Diff 算法的基石。

当你看到 React 文档里写的“Diff 算法的时间复杂度是 O(n)”时，这个 O(n) 是怎么来的？它就是由无数次“单节点 Diff”累加起来的。

React 为了优化性能，做了一个极其重要的假设：对于同一层级的元素比较，React 只会比较同类型的节点。

这意味着，React 不会去比较一个 div 和一个 span 的子节点，它只会比较两个 div 的子节点。

代码示例 3：层级隔离

// 父组件
function Parent() {
  return (
    <div>
      <div>Child 1</div>
      <span>Child 2</span> {/* 这里类型变了！ */}
      <div>Child 3</div>
    </div>
  );
}

React 在处理这个父组件的子节点时：

1. 遇到第一个 div，继续递归。
2. 遇到第二个 span，React 会发现类型变了。
3. 关键点来了：React 不会去比较 <div>Child 1</div> 的子节点和 <span>Child 2</span> 的子节点（虽然它们都是文本节点，且内容相同）。
4. React 会直接认为 <div>Child 1</div> 是一个节点，<span>Child 2</span> 是另一个节点。然后对它们分别进行单节点 Diff。

这就是为什么 React 不去全树 Diff 的原因。如果 React 比较一个 div 和一个 span，那它的算法复杂度会瞬间爆炸到 O(n^3) 甚至更高。通过限制“同层级比较同类型”，React 把复杂度降到了 O(n)。

所以，单节点 Diff 算法不仅仅是比较两个节点，它还隐含了“层级隔离”的策略。它告诉 React：“兄弟，别管那个 span 了，先搞定这个 div，那个 span 是另一个世界的事。”

第六部分：Key 的艺术与科学

前面我多次提到 key，现在我要正式地强调一下：Key 是 React 性能优化中最容易被滥用，也是最重要的一把双刃剑。

1. 为什么要用 Key？

React 需要一个稳定的标识符来告诉浏览器：“嘿，这个 DOM 节点我已经认识你了，别把它扔了。”

如果没有 Key，React 会默认使用索引作为 Key。

代码示例 4：Key 丢失的灾难

function List() {
  const items = ['Apple', 'Banana', 'Cherry'];

  // 每次渲染，items 都是同一个数组引用，所以 React 认为这是同一个列表
  // 但是！如果父组件重新渲染，items 是从 props 传进来的呢？
  // 或者 items 是通过 filter/filter/map 生成的？
  // 或者 items 是通过 splice 改变的？

  return (
    <ul>
      {items.map((item, index) => (
        // 危险！如果列表顺序变了，或者插入了项，index 就会乱套
        <li key={index}>{item}</li>
      ))}
    </ul>
  );
}

假设 items 变成了 ['Banana', 'Cherry', 'Apple']。

React 的单节点 Diff 过程：

1. 旧 key=0 (Apple) vs 新 key=0 (Banana)。React：“哦，这是同一个位置，Apple 变成了 Banana？更新一下文本内容。”
2. 旧 key=1 (Banana) vs 新 key=1 (Cherry)。React：“哦，Banana 变成了 Cherry？更新一下。”
3. 旧 key=2 (Cherry) vs 新 key=2 (Apple)。React：“哦，Cherry 变成了 Apple？更新一下。”

结果：虽然内容变了，但是 React 以为只是内容变了，它只是更新了文本节点。这对于文本节点来说，性能很好。但是，如果 li 里面包含一个 <input> 或者 <button> 呢？

如果 <input> 里面已经有了输入的文字，React 更新了文本内容，那个 <input> 的值会被覆盖掉！ 这就是为什么列表项里有输入框时，千万不能用 index 作为 key。

2. Key 的最佳实践

• 唯一性：Key 必须在列表中是唯一的。数据库的主键是最好的选择。
• 稳定性：Key 不应该频繁变化。如果 Key 每次渲染都变（比如用 Math.random()），React 就会认为每次都是全新的节点，导致整个列表被销毁重建，性能极差。

代码示例 5：正确的 Key 使用

// 假设数据来自 API
const users = [
  { id: 1, name: 'Alice' },
  { id: 2, name: 'Bob' },
  { id: 3, name: 'Charlie' }
];

function UserList() {
  return (
    <ul>
      {users.map(user => (
        // 使用 id 作为 key，这是最标准的做法
        <li key={user.id}>{user.name}</li>
      ))}
    </ul>
  );
}

第七部分：React 的“偷懒”哲学

最后，我想聊聊 React 单节点 Diff 算法背后体现的设计哲学。

React 的核心团队，也就是那个叫 Dan Abramov 的哥们，他一直强调 React 是声明式的。

什么是声明式？就是你告诉 React“我想看到什么”，而不是“怎么做”。

在 imperative（命令式）编程里，你要手动操作 DOM，比如 document.getElementById('btn').remove()，然后 document.createElement('div')。你需要精确地控制每一步。

在 React 里，你只需要写 JSX。React 会自动帮你做单节点 Diff。

为什么 React 要这么做？

1. 代码更简洁：你不需要写一堆丑陋的 DOM 操作代码。
2. 状态同步更容易：你只需要修改数据，UI 会自动更新。
3. 性能优化更透明：虽然 Diff 算法在底层，但 React 给了你优化手段（Key，useMemo，shouldComponentUpdate 等）。

单节点 Diff 算法就是 React 为了实现“声明式 UI”而牺牲了一些“微观性能”换来的结果。它不追求完美的全树比对，它追求的是“大多数情况下的快速更新”。

第八部分：实战中的陷阱——为什么你的 React 变慢了？

讲了这么多原理，我们来看看在实际开发中，哪些场景会让单节点 Diff 算法“翻车”。

1. 大列表渲染

如果你有一个包含 10000 条数据的列表，每次父组件更新导致整个列表重新渲染。

React 会进行 10000 次单节点 Diff。

虽然 React 做了同层级比较的优化，但 10000 次循环在 JavaScript 主线程上仍然是昂贵的。

解决方案：

• 虚拟列表：只渲染可视区域内的节点。React 的单节点 Diff 只针对可视区域的节点进行。
• key 的正确使用：确保 key 的查找是 O(1) 的（哈希表查找），而不是 O(n) 的（数组遍历）。

2. 不必要的重渲染

如果一个父组件有很多子组件，父组件状态一变，所有子组件都重新渲染。

即使子组件的单节点 Diff 发现“哎，我的 props 没变”，它还是会走一遍流程。虽然这很快，但也是浪费。

解决方案：

• React.memo：这是一个高阶组件，它会在渲染前检查 props 是否变化。如果没变，直接跳过渲染。

代码示例 6：React.memo 的使用

const ExpensiveComponent = React.memo(function ExpensiveComponent({ data }) {
  console.log('Rendering ExpensiveComponent'); // 只有 data 变了才会打印
  return <div>{data}</div>;
});

function Parent() {
  const [data, setData] = useState('Initial');

  return (
    <div>
      <button onClick={() => setData('New Data')}>Change Data</button>
      <ExpensiveComponent data={data} />
    </div>
  );
}

第九部分：深入 Fiber —— 单节点 Diff 的舞台

你可能会问：“老师，你刚才说的那些函数，React 内部真的这么写吗？Fiber 架构呢？”

好问题。React 16 引入了 Fiber 架构，就是为了解决单节点 Diff 算法在大规模应用中的性能问题。

在 Fiber 之前，React 的渲染是同步的，一旦开始渲染，就会阻塞主线程，导致页面卡顿。

Fiber 把渲染过程拆解成了一个个微小的任务。当 React 执行单节点 Diff 时，它不会一口气把整个树比完。它会像切香肠一样，把 Diff 过程切成很多块。

代码示例 7：Fiber 节点结构

// Fiber 节点结构（简化版）
function FiberNode(type, key, props) {
  this.type = type;       // 对应 React 元素的 type
  this.key = key;         // 对应 React 元素的 key
  this.props = props;     // 对应 React 元素的 props

  // 这就是那个“旧节点”和“新节点”在 Fiber 树里的位置
  this.alternate = null;  // 指向旧 Fiber 节点

  // 子节点和兄弟节点
  this.child = null;
  this.sibling = null;

  // DOM 引用
  this.stateNode = null;  // 指向真实的 DOM 节点
}

在 Fiber 树的构建过程中，React 会利用 alternate 属性来快速定位旧节点。

1. 当 React 创建新 Fiber 节点时，它会检查是否有 alternate 属性。
2. 如果有，说明这是复用节点。React 会直接把 stateNode（DOM）指向旧节点的 stateNode。
3. 然后更新 props。
4. 如果没有 alternate，说明这是新节点，创建新的 DOM。

这个过程非常快，因为它直接操作的是 JavaScript 对象，而不是直接操作 DOM。等到 Diff 完成后，React 再一次性把变化应用到真实的 DOM 树上。

第十部分：总结——单节点 Diff 的精髓

好了，我们讲了这么多，其实单节点 Diff 算法的精髓就浓缩在下面这行伪代码里，但我会用更通俗的语言再解释一遍。

function reconcile(oldNode, newNode) {
  // 1. 看脸（Type）
  if (oldNode.type !== newNode.type) {
    return destroyAndCreate(oldNode, newNode);
  }

  // 2. 看名字（Key）
  if (oldNode.key !== newNode.key) {
    return destroyAndCreate(oldNode, newNode);
  }

  // 3. 复用！
  updateDOM(oldNode.dom, newNode.props);

  // 4. 递归处理孩子
  reconcileChildren(oldNode, newNode);
}

这就是 React 的秘密武器。

• Type 是身份证明，没它不行。
• Key 是定位系统，没它容易乱。
• Props 是外貌特征，变了就改。
• Fiber 是执行架构，让这个算法更流畅。

作为开发者，我们不需要自己去写这个算法。但是，理解它，能让我们写出更好的代码。

当你下次写代码时，如果你不小心把 key={index} 写在了列表里，你应该想起这个算法。你应该想起 React 会如何因为 index 的变化而误以为你换了一个人，从而导致 DOM 节点的销毁和重建。

当你下次遇到性能问题时，你应该想起这个算法。你应该想起 React 是如何通过“同层级比较同类型”来避免全树 Diff 的。

React 的单节点 Diff 算法，就像是一个精明的管家。它不会把你的家具都扔掉重新买，它只会帮你把桌子擦干净，把椅子挪到合适的位置。只要你知道怎么正确地使用它（给它正确的 Key），它就能让你和你的浏览器相处得非常愉快。

好了，今天的讲座就到这里。记住，代码是写给人看的，顺便给机器运行。理解了 React 的逻辑，你就能写出更优雅、更高效的 React 代码。下课！