React与Vue虚拟DOM与Diff对比

可视化演示

动态演示React与Vue虚拟DOM的核心机制，通过总览/传输/转换/输出四种模式展示关键概念与交互流程。

虚拟DOM原理——为什么先画图纸

老张的装修队以前干活，客户说“改一下玄关的鞋柜”，他们直接请来挖掘机把整栋房子推平重盖。这听起来荒唐，但浏览器处理真实 DOM 操作时就是这样：每改一次 DOM 节点，浏览器就要重新计算样式、重新布局、重新绘制，改的次数越多，页面卡得越厉害。频繁操作真实 DOM，就像频繁推倒重盖房子，每一次都代价高昂。

于是聪明的装修队不再直接动工，而是先在纸上画一份设计图。这份设计图就是虚拟 DOM（Virtual DOM）：它不是真实的 HTML 标签，而是一棵由 JavaScript 普通对象组成的树。每个节点叫 vnode，记录着“这里有个 div、它有这些属性、下面挂着这些子节点”。改设计图只需要动笔，一行文字、一个对象，成本极低。

真实 DOM 操作贵在哪？贵在浏览器要经历一系列“重排重绘”流水线。而虚拟 DOM 把改动集中到 JS 对象层面，最后才一次性提交给浏览器，就像装修队先在图纸上反复推敲，确定方案后再进场施工，把几十次返工压缩成一次精准的施工。

所以装修队总结出一条经验：图纸怎么改都不心疼，墙不能随便砸。虚拟 DOM 的价值，就是把昂贵的“砸墙”变成便宜的“改图”，这就是它的核心价值。

虚拟DOM工作流程——画图、审图、施工四步法

R 队和 V 队虽然风格不同，但接单后的流程出奇一致。第一步是“量房”：组件收到新的状态（state）后，重新执行渲染函数，把当前界面完整地画成一份新图纸，这就是 render 阶段。第二步是“画图”：渲染函数返回的是一棵新的虚拟 DOM 树，树上每个节点都是轻量的 JS 对象。

第三步是“审图”：装修队长左手拿着旧图纸，右手拿着新图纸，逐层比对，找出所有变化的房间和墙面的位置，这个动作就是 diff。第四步是“施工”：队长拿着差异清单，派工人精确修改真实 DOM 中对应的位置，这个动作叫 patch。四步走完，页面就完成了更新。

注意一个关键点：diff 阶段只发生在 JS 对象的“图纸空间”里，完全没有触碰真实 DOM。直到 patch 阶段才把差异一次性提交给浏览器。这就像图纸评审会上可以随意讨论方案，确定方案后工人只跑一趟工地，避免了传统装修队“改一次拆一次房”的浪费。

这套流程最妙的地方在于：真实 DOM 的更新被集中在了最后一步，前面的所有环节都是在“纸面”上完成的低成本推演。R 队和 V 队的区别，只在于第三步“审图”用了完全不同的策略。

Diff核心思想——找差异的三条铁律

两家装修队都知道，最理想的审图方案是算出“把旧房子改成新房子”的最小改动方案——比如移动几堵墙、拆除几个房间。但这件事在计算机里属于“树编辑距离”问题，复杂度高达 \(O(n^3)\)，节点一多，图纸还没审完，客户都等睡着了。所以两队都放弃了完美方案，改用工程化的近似策略。

第一条铁律：只比较同一层，不跨层移动。在真实项目里，把整个组件子树从一层挪到另一层的操作极其罕见，所以两家都默认“跨层移动 = 销毁重建”。有节点从第 2 层搬到第 3 层？两边直接把它卸了重新装，不做任何移动优化。第二条铁律：按广度逐层扫描，上一层比完再比下一层，绝不回头。第三条铁律：用 key 给节点配身份证。在同一层的兄弟节点列表里，key 帮算法快速判断“这个新节点以前是不是那一个旧节点”，没有 key 就只能靠位置蒙。

这三条铁律把原本指数级的比较难题，压缩成了线性的扫描任务，复杂度从 \(O(n^3)\) 直降到 \(O(n)\)。所谓 Diff 算法，本质就是“在工程可接受的误差内，用最小的代价找出新旧两棵树的差异”。就像装修队审图时不去推演墙体移动的最优路径，而是简单地逐层标记“哪间房变了，哪间房没变”。

这三条铁律是两支装修队的“行规”。但行规之下，R 队和 V 队的实操风格截然不同，我们分别去看看他们是怎么审图的。

React Diff策略——R队的标准排查法

R 队审图有一套严格的标准动作。队长站在门口，先看客厅（根节点）的“用途”变没变——在代码里这就是节点的 type。如果客厅变成了车库，类型都不同，那整栋房子直接推倒重盖，里面的所有房间都不必再对比。如果 type 相同，队长才继续检查客厅的家具摆放（props），然后进入下一层，逐一检查每个房间。

这就是 React 三大假设的第一条：不同类型的元素会产生不同的树，直接重建。第二条：开发者用 key 提示哪些子元素是稳定的，让列表对比时能复用节点。第三条：跨层移动极少发生，所以不深入处理。这三条假设像极了装修行业经验：用途不同的房间没法复用，有门牌号的房间才好认，没人会没事儿把整间房子搬到二楼去。

在层内列表对比时，React 的做法很朴素：把新旧两个列表按索引顺序位对齐，逐个比较。如果同一个位置上 key 相同，就认为这个节点可以复用，只更新变化的部分；如果 key 对不上，就标记为增删或重建。如果一个列表只有中间一个位置变了，React 也只会处理那一个位置，不过它不会像 Vue 那样聪明地从两头同时夹击。

R 队的方法稳定可靠、可预测性强，唯一的代价是：它不像 V 队那样有一张“key 快速定位表”，遇到列表中有节点被删掉再插回前面时，需要多花几步搬运。这正是 Vue 装修队琢磨出的改进点。

Vue Diff策略——V队的双端夹击

V 队审图的姿势比 R 队更灵活。他们不从门口一间间走到头，而是派两个人：一个从走廊最左端开始，一个从右端开始，同时向中间汇合。每轮比较，先看最左边的房间是否有变化，再看最右边的房间是否有变化，哪边相同就先处理哪边，两头同时推进。

这就是 Vue2 经典的双端比较（Double-End Diff）。每轮循环有四路判断：旧头对新头、旧尾对新尾、旧头对新尾、旧尾对新头，任一路命中就说明节点可以复用，剩下的交给 key 映射表快速查找。当列表里某个节点被删掉了，V 队能立刻发现尾部缺失，直接把它标记删除，而不必像 R 队那样把整段列表重新对位。

到了 Vue3，V 队又多了一把利器：编译时 patchFlag。因为 Vue 的模板是编译器处理的，它能在编译阶段就看出哪些地方是静态文本、哪些地方是动态属性，并在虚拟 DOM 节点上贴上“这里会变”的标记。运行时 diff 看到静态标记直接跳过，连比较都省了，只盯着真正会变的节点处理。

V 队的“双端夹击 + 门牌号快速查表 + 编译期贴标记”三件套，让它在处理列表增删和模板渲染时都比 R 队更省力。门牌号的价值在此时展露无遗：不用把所有房间都排查一遍，凭 key 就能直接定位要改的那间房。

两框架对比——R队与V队的正面交锋

现在让 R 队和 V 队同台竞技，看看两支装修队的真实差距。先说相同点：两队都用虚拟 DOM 做中间层，都遵守“同层比较 + key 复用”这两条铁律，最终都以 patch 的方式更新真实 DOM，这是行业共识，不是某家的独家秘笈。

真正的差异在第二层。R 队的 React 是纯运行时 diff：它不关心你的代码是怎么写的，每次更新都从根节点开始，把整棵虚拟 DOM 树扫一遍，靠三条假设砍掉不必要的比较。V 队的 Vue 则是运行时 + 编译时组合拳：编译阶段就通过 patchFlag 标记出了“哪些节点是死的”，运行时只扫活的节点，天然跳过静态内容。

因此在同等规模下，\(T_{Vue}\) 的实际比较节点数明显少于 \(T_{React}\)，尤其适合模板大量、交互相对固定的中后台页面。而 React 的纯运行时方案换来了更高的灵活性——JSX 可以写在任何地方，diff 逻辑统一且可预测，大型复杂应用里生态更成熟、掌控感更强。没有绝对的谁好谁坏，只有匹配不匹配。

总结成一句：R 队靠“标准流程 + 经验假设”保证不犯错，V 队靠“提前做功课 + 精准定位”节省体力。两支队伍没有绝对的优劣，而是给人留下了两个不同的优化思路——这也是为什么理解 diff 差异，能帮你在真实项目里做出更聪明的渲染决策。

性能优化建议——让装修队省力的诀窍

既然已经摸清了两支装修队的工作方式，那我们作为“客户”，怎么配合才能让他们更快干完活？第一个诀窍：把门牌号挂对。列表渲染时给每项一个稳定且唯一的 key，比如数据库里的 id。最忌讳的是用数组下标 index 当 key——列表一增删，下标全部错位，React 和 Vue 都会把原节点误判成新节点，导致一堆不该重建的节点被重建，甚至引发输入框内容错乱。

第二个诀窍：别随便改房子的承重结构。顶层组件的根标签要从 <div> 切成 <section>，或者把一个组件从“渲染 A 组件”改成“渲染 B 组件”？类型一变，React 会把整棵子树推倒重建，你精心优化的内部组件全部白搭。保持顶层结构稳定，diff 才有机会深入内层做精细比较。

第三个诀窍：让不需要装修的房间自动锁门。React 里用 React.memo 或 PureComponent 对组件做浅比较，让 props 没变的子组件跳过重新渲染；Vue 里配合 computed 自动缓存计算结果。这样父组件无论怎么折腾，子组件只要“没收到新指令”就直接说：我这间房不用改。下面这个复用率公式，就是衡量门牌号和结构做得好不好的标尺。

把这三个诀窍做到位，你写出来的组件哪怕面对每秒几十次的数据刷新，也能让页面保持流畅。理解虚拟 DOM 和 Diff，不是为了背概念，而是为了在写代码时知道：每一次渲染，装修队都在按什么规则为你省下真金白银。

AI 应用场景

Python 演示

def react_style_scan(old_list, new_list):    """React 风格：按索引从前往后逐一比对"""    ops = []    n = max(len(old_list), len(new_list))    for i in range(n):        old = old_list[i] if i < len(old_list) else None        new = new_list[i] if i < len(new_list) else None        tag = "复用" if old == new else "更新"        ops.append((old, new, tag))    return ops  def vue_style_scan(old_list, new_list):    """Vue 风格：双端指针同时向中间扫描"""    ops = []    old = list(old_list)    new = list(new_list)    while old and new:        if old[0] == new[0]:            ops.append((old[0], new[0], "头部匹配"))            old.pop(0)            new.pop(0)        elif old[-1] == new[-1]:            ops.append((old[-1], new[-1], "尾部匹配"))            old.pop()            new.pop()        elif old[0] == new[-1]:            ops.append((old[0], new[-1], "头尾复用"))            old.pop(0)            new.pop()        elif old[-1] == new[0]:            ops.append((old[-1], new[0], "尾头复用"))            old.pop()            new.pop(0)        else:            ops.append((old[0], new[0], "未知需查表"))            old.pop(0)            new.pop(0)    return ops  def reuse_rate(ops):    """统计可复用节点的比例"""    reused = sum(1 for _, _, tag in ops if "复用" in tag or "匹配" in tag)    return reused / max(len(ops), 1)  if __name__ == "__main__":    old_rooms = ["客厅", "卧室", "书房", "厨房"]    new_rooms = ["客厅", "书房", "主卧", "厨房"]    print("React 风格扫描：")    for step in react_style_scan(old_rooms, new_rooms):        print("  ", step)    print("Vue 风格扫描：")    for step in vue_style_scan(old_rooms, new_rooms):        print("  ", step)    print("Vue 风格复用率：", reuse_rate(vue_style_scan(old_rooms, new_rooms)))

1. def react_style_scan(old_list, new_list):模拟 React 在层内按索引顺序逐个比较子节点。
2. n = max(len(old_list), len(new_list))按较长列表的长度对位，保证每个位置都被检查到。
3. tag = "复用" if old == new else "更新"同位置同值判定为可复用，否则标记为需要更新。
4. while old and new:Vue 双端比较的循环条件，只要有未处理的节点就继续扫描。
5. elif old[-1] == new[-1]:尾部节点相同直接复用，这是双端比较省力的关键。
6. elif old[0] == new[-1]:旧头部跑到新尾部也能识别，避免了 React 式的整段重排。
7. elif old[-1] == new[0]:旧尾部跑到新头部同样可以捕获复用机会。
8. ops.append((old[0], new[0], "未知需查表"))两头都无法匹配，交给 key 映射表做精确查找。
9. if __name__ == "__main__":直接运行脚本即可看到两种策略的扫描轨迹差异。

常见误区

面试题