在虚拟 DOM 的实现中，Diff 算法的效率直接决定了 UI 更新的性能。如果不经优化地比较两棵节点树，时间复杂度会达到不可接受的程度，而 React 通过一系列预设的启发式策略将复杂度控制在了线性级别。理解这里面的性能差异，有助于理解为什么 React 能在复杂应用中仍保持流畅体验。
传统 Tree Diff 的 O(n³) 复杂度
传统的通用两棵树对比算法，需要在三件事之间反复计算：
- 找到两个树之间的节点对应关系（判断节点是否“同一”）。
- 计算最小编辑距离：确定通过增、删、改、移哪些操作，能将旧树变成新树。
- 执行这些操作的成本评估。
在一棵复杂的 UI 树中，这种算法需要遍历旧树的每个节点（O(n)），对每个节点再遍历新树寻找可能的匹配（O(n)），然后计算这些匹配对应的子树编辑代价（可能还需要 O(n)），整体复杂度约为 O(n³)。对于包含上千个节点的页面，这种计算量会迅速让页面卡顿甚至无响应——这在实际产品中是完全不可行的。
React Diff 的三大优化策略
React 意识到真实 UI 场景下很多“理论上可能”的情况极少出现，因此引入了一系列预设假设，将复杂度从 O(n³) 降到了近似 O(n)。
1. 仅进行同层比较
React 默认只比较同一层级的节点，不会尝试将节点与跨层级的节点进行匹配。如果发现一个节点在旧树和新树中处于不同层级，React 会直接销毁旧节点及其子树，并在新位置重新创建，而不是进行复杂的移动计算。这符合绝大多数 UI 更新的实际模式——页面模块很少大幅度跨层移动。
// 旧树层级
<parent>
<child /> // 旧位置
</parent>
// 新树变为
<parent />
<child /> // 新位置，跨层级
// React 的行为：直接销毁旧 child，创建新 child这种策略让比较范围从“任意两节点之间”缩小为“同层兄弟节点之间”，瞬间砍掉大量冗余计算。
2. 不同类型节点直接重建
当比较同层的两个节点时，React 首先判断它们的类型：
- 如果类型不同（比如
<div>变成了<span>，或<Button />变成了<Link />），React 会认为整个子树不再可复用，直接销毁旧节点及其所有后代，并从头创建新节点。 - 只有当类型相同时，React 才会继续深入比较该节点的属性和子节点。
// 旧树
<button>
<span>提交</span>
</button>
// 新树
<a href="/">
<span>提交</span>
</a>
// React 行为：销毁整个 button 及其子 span，重新创建 a 和其子 span这个假设避免了“类型变了但子节点还复用”的场景下的复杂递归对比，进一步减少不必要的计算。在实际产品中，标签或组件类型变化的节点往往意味着整块 UI 的重构，重新创建是最合理的做法。
3. 使用 key 优化列表对比
对于同层级的列表节点（如多个 <li>），React 默认通过顺序对比：旧列表的第 0 项与新列表的第 0 项比，第 1 项与第 1 项比，以此类推。但如果列表项发生了增/删/排序，这种顺序对比会导致大量误匹配，每个位置都可能识别为不同的节点，从而执行不必要的销毁和创建。
key 属性的作用：通过给每个列表项分配一个唯一且稳定的 key，React 可以识别出哪些节点只是移动了位置，哪些是新增的，哪些需要删除。从而将操作从“销毁+重建”优化为“移动或更新”。
// 旧列表
<ul>
<li key="a">A</li>
<li key="b">B</li>
</ul>
// 新列表（在头部插入一项）
<ul>
<li key="c">C</li>
<li key="a">A</li>
<li key="b">B</li>
</ul>
// 没有 key：React 会认为旧 A 变成了 C（销毁旧 A，创建 C），
// 旧 B 变成了 A（销毁旧 B，创建 A），最后再创建 B。
// 有 key：React 识别出 key="a" 和 key="b" 仍存在，只需新增 key="c" 一项。从性能角度看，带 key 的列表对比避免了大量 DOM 操作，尤其在列表长且频繁变化的场景（如聊天消息、表格数据），性能差异会非常显著。
性能差异的实际体现
假设一个真实的 UI 树包含约 500 个节点（中型后台页面），传统 O(n³) 算法需要进行约 500³ = 1.25 亿次比较，这在毫秒级内几乎不可能完成，会直接导致浏览器卡死。而 React 的近似 O(n) 策略只需进行约 500 次同层级比较，加上类型判断和 key 匹配，总计算量控制在几百到几千次，完全可以在每一帧（16.6ms）内完成，保证 60fps 的流畅度。
即使对于存在大量节点的应用（如无限滚动列表），配合虚拟列表和合理的 key 策略，React 的 Diff 也能保持高性能。实际项目中，只要遵循“避免跨层级移动”、“列表必须赋稳定 key”、“类型不变则组件可复用”的原则，就基本不会触发明显的 Diff 瓶颈。
总结
| 对比维度 | 传统通用 Diff | React Diff |
|----------|---------------|------------|
| 时间复杂度 | O(n³) | 近似 O(n) |
| 跨层级移动 | 尝试匹配，计算代价 | 不匹配，直接销毁重建 |
| 元素类型变换 | 尝试复用子节点 | 整树重建 |
| 列表变动 | 顺序对比，大量误匹配 | 通过 key 精准识别移动/复用 |
| 是否可行 | 复杂 UI 完全不可用 | 工程中高度可行 |
React 通过放弃“穷举最优解”而采用“启发式近似最优解”，用不可见的小量 DOM 冗余操作换来了线性的计算复杂度，这正是 React 能够支撑大型、高频交互应用的核心原因之一。