2025年，前端还需要虚拟DOM吗

Vue 3.6的新变化-Vapor Mode

前几天，刷到了一篇文章介绍Vue 3.6 ，里面提到Vue 3.6 带来的一个重要更新是一种叫做Vapor Mode的新渲染模式，这种渲染模式与我们熟悉的虚拟DOM，创建VNode的形式不同，它在编译期直接把模板编译成精准DOM操作，不再需要写VNode、也不再采用DIFF算法进行新旧节点对比，从而使构建的包更小、跑得更快。官方给出的性能对比如下：

场景	传统 VDOM	Vapor Mode
Hello World 包体积	22.8 kB	7.9 kB ⬇️ 65%
复杂列表 diff	1×	0.6× ⬇️ 40%
内存峰值	100%	58% ⬇️ 42%

可以看见，首屏的js代码降低了2/3 ，运行时内存几乎只要原本的1/2 。Vapor Mode重构了Vue 的底层渲染机制，使得我们能够用更加贴近于原生DOM的方式，有效的提高了Vue的性能潜力。

技术的发展总是这样长江后浪推前浪，在后浪风卷而来之前，我想为前浪虚拟DOM做一个小小的回顾。

写在虚拟DOM之前

在虚拟DOM诞生之前，前端开发框架有且只有一个霸主，就是Jquery ，JQuery 诞生于2006年，它的创造者John Resig 是一个独立开发者，现在是Mozilla 项目里的重要成员。在当时，JQuery 凭借简洁的API大大地简化了DOM的操作，它提出的内置浏览器兼容、链式调用、事件委托等机制相比于原生的js操作，显得闪闪发光，吸引了众多开发者使用，在前端的发展史留下了浓墨重彩的一笔。

// 2005年前的原生DOM操作，原始且繁琐😣
function renderList(data) {
  // 获取列表容器
  var listContainer = document.getElementById('productList');
  if (!listContainer) {
    // 处理容器不存在的兼容问题
    listContainer = document.createElement('ul');
    listContainer.id = 'productList';
    document.body.appendChild(listContainer);
  }
  
  // 清空现有内容
  while (listContainer.firstChild) {
    listContainer.removeChild(listContainer.firstChild);
  }
  
  // 遍历数据创建列表项
  for (var i = 0; i < data.length; i++) {
    var item = data[i];
    var li = document.createElement('li');
    
    // 设置样式（需考虑IE的兼容写法）
        // 设置样式（需考虑IE的兼容写法）
    li.style.color = '#333';
    li.style.fontSize = '14px';
    // IE不支持textContent，需用innerText
    if (typeof li.textContent === 'undefined') {
      li.innerText = item.name;
    } else {
      li.textContent = item.name;
    }
    listContainer.appendChild(li);
  }
}

// JQuery出现后操作DOM，优雅！elegant~😍
function renderList(data) {
  var $list = $('#productList');
  if ($list.length === 0) {
    $list = $('<ul id="productList">').appendTo('body');
  }
  
  $list.empty().css({
    'list-style': 'none',
    'padding': '0'
  });
  
  $.each(data, function(i, item) {
    $('<li>')
      .text(item.name)
      .css({
        'color': '#333',
        'font-size': '14px',
        'padding': '5px'
      })
      .click(function() {
        alert('点击了' + $(this).text());
      })
      .appendTo($list);
  });
}

但是，随着Web应用的复杂度提高，JQuery 的性能缺陷被越放越大。在下面的筛选商品场景下，JQuery对列表的处理十分粗暴又低效，同时它也缺少一些今天我们很熟悉的前端框架特性，比如组件化、状态管理等等。

// 低效的JQuery列表更新
function updateList(filteredData) {
  $('#productList').empty(); // 清空列表（触发重排）
  filteredData.forEach(item => {
    $('#productList').append(`<li>${item.name}</li>`); // 触发重排+10086
  });
}

Jquery存在的这些问题，推动了后续的前端框架规范化发展，同时也为虚拟DOM的诞生埋下了伏笔。

虚拟DOM的诞生与原理

2011年，是Facebook 创建的第7年，这家以社交软件为核心的公司，在这一年的用户数量达到了8亿，也就意味着全球每7个人里就有1个Facebook 用户。而对于一个社媒软件，广告是其盈利的t0业务。为了搭建一个能够触达8亿用户的广告系统前端，程序员Jordan Walke 构思并开发了React的1.0版本。当时的他意识到了直接操作DOM对于性能的开销太大。年轻的Jordan想起前辈John曾告诉过他：

计算机科学领域的任何问题都可以通过增加一个间接的中间层来解决。 ------David John Wheeler

例如，虚拟机技术在硬件和操作系统之间有一层虚拟机，Docker在操作系统和应用之间有一层虚拟层，此外还有代理服务、消息队列、缓存等等都采用了中间层的理念。因此他想到，是否也能够通过建立一个虚拟的DOM来对实际DOM进行操作？

理论成立，实践开始。2013年，React 正式对外发布，并定义了虚拟DOM概念：在内存中利用JavaScript模拟出一棵 DOM 树，当状态改变时，先更新虚拟 DOM，接着通过DIFF算法找出差异，最后精准地更新真实 DOM。

虚拟DOM的基本结构

虚拟DOM的本质是一个JavaScript 对象，例如一个简单的Vnode节点如下

// 虚拟DOM节点示例
const vnode = {
  tag: 'div',
  props: { className: 'container' },
  children: [
    { tag: 'p', props: {}, children: 'Hello World' },
    { tag: 'button', props: { onClick: handleClick }, children: '点击我' }
  ]
};

DIFF算法

DIFF算法是虚拟DOM概念中最关键的一部分，它用来对比两颗新旧DOM树的差异，并只把不同的部分进行更新，直接决定了DOM能够实现高效的更新。DIFF算法有三个基本原则：

1. 同级比较。子节点只会和新的子节点进行对比，不跨层级。
2. 类型匹配。如果两个节点的标签类型不同，直接认为是不同节点，替换掉。
3. key标识。对于列表，可以通过key来进行标识不同的节点，保证唯一性。

React的DIFF算法

• 单节点对比，根据key和类型以及层级进行判断

// React单节点diff
function isSameNode(oldVNode, newVNode) {
  // 1. 先判断key是否相同
  if (oldVNode.key !== newVNode.key) return false;
  // 2. 再判断标签类型是否相同
  if (typeof oldVNode.type !== typeof newVNode.type) return false;
  // 3. 原生标签判断标签名，组件判断组件类型
  if (typeof oldVNode.type === 'string') {
    return oldVNode.type === newVNode.type;
  }
  return true;
}

• 列表对比原则-采用首尾指针法

分别设置旧列表的头指针（oldStartIdx）、尾指针（oldEndIdx）
分别设置新列表的头指针（newStartIdx）、尾指针（newEndIdx）
按顺序进行对比：
旧头 vs 新头
旧尾 vs 新尾
旧头 vs 新尾
旧尾 vs 新头
如果以上对比都不匹配，则通过 key 建立映射表查找可复用节点

Vue的DIFF算法

• 单节点对比-双端比较法

Vue 2 采用的双端比较法与React的首尾指针法思路相似，但在处理顺序和移动逻辑上略有不同：同时从新旧列表的两端开始比，在每轮比完后移动相应的指针，当旧列表先遍历完时，批量添加剩余新节点；而当新列表先遍历完时，批量删除剩余旧节点。

• 列表对比原则-最长递增子序列

Vue 3 对DIFF算法进行了重大优化，引入了 "最长递增子序列" 算法处理列表的重排序问题，首先通过 key 建立新旧节点的映射关系，然后找出找出不需要移动的节点（形成递增子序列），最后只移动需要改变位置的节点

虚拟DOM的发展和迭代

React

• React 15奠定了虚拟DOM DIFF更新算法的基础，此时采用的是同步递归的更新策略，这种策略存在的问题是：当更新的节点数量比较多的时候，会导致主进程被长时间阻塞。
• React 16 提出了**Fiber**架构，从而使得虚拟DOM节点拆分为可以中断、恢复、优先级排序的工作单元。这种架构进一步细分了虚拟DOM更新的资源获取，保证了主进程不会被阻塞，使得应用的响应性得到保障。
• React 18 则进一步引入了并发渲染，基于Fiber架构实现了优先级的调度，允许高优先级的渲染先于低优先级执行。

Vue

• Vue 2 为虚拟DOM的DIFF算法提供了双端比较和基于key的列表对比，但是并没有区分静态节点和动态节点，这会导致它对于动态内容的渲染能力有限。
• Vue 3 引入了静态提升机制，这个机制能够把模板中的静态节点提升到渲染函数之外，这样就能够避免在后续的比较里对这些不会改变的资源进行无效比较。其次，Vue 3 通过PatchFlag标记动态节点，在DIFF算法的过程中只关注带有PatchFlag的节点及其动态属性，缩小了比较的范围，进一步提升了性能
• Vue 3的虚拟DOM支持按需更新，对于组件中的不同动态部分，会生成独立的更新函数，当对应的状态发生变化时，只执行相关的更新函数，避免了整个组件的重新渲染和虚拟DOM比较。

其它框架

• Preact 。基于React 的虚拟DOM机制进行开发，采用的属性命名和数据结构更为简洁，DIFF算法也避免了一些不必要的比较，但性能接近于React。
• Snabbdom。这是一个专注于虚拟DOM的库，同样在设计上采用了更加简洁的处理，同时，支持模块化虚拟DOM组件的功能，在保证功能的前提下减少了冗余的代码。

面临的问题

事物是发展的，尽管虚拟DOM技术的诞生就是为了应对web应用开发日益复杂导致的性能问题，但随着web应用的复杂度进一步提示，虚拟DOM也迎来了自己的缺点和局限性。

1. 运行时候的开销问题。现代的前端框架Vue 和React 一定比过去的JQuery 要好吗？答案其实是不一定，在一些简单项目里JQuery 或许更好用。虚拟DOM在提升性能的同时也付出了相应的代价，一是Diff算法的计算成本，二是虚拟DOM树的内存占用。尽管大家都在对DIFF算法进行优化，但再怎么优化，在面对大规模DOM树的时候还是需要进行大量的对比计算。同时，虚拟DOM树的数据结构存在于内存中，对于大型应用，生成的虚拟DOM树会占用大量的内存。
2. 性能表现。对于大数据渲染以及高频次更新的场景，比如股票交易的展示，大型聊天室内容，每次状态改变都需要进行立刻虚拟DOM的更新、DIFF比较、真实DOM同步，这些场景里的虚拟DOM性能表现并不好。
3. 与浏览器的原生能力有冲突。浏览器自身对于DOM操作有优化机制，比如批量DOM操作可以减少重排重绘的次数。但虚拟DOM的DIFF更新过程通常是按照自己的逻辑进行的，可能会将本可以批量处理的 DOM 操作拆分成多个单独的操作，从而失去浏览器优化带来的好处。虚拟DOM作为一个抽象层也会导致一些基于原生DOM的浏览器特性难实现，比如Web components的一些高级特性。

后浪：编译时优化方案

基于上述的这些问题，一些后来的前端框架开始尝试不采用虚拟DOM的方案，其中编译时优化的思路目前来看最符合未来的方向。

Svelte

Svelte 是编译时优化方案的典型代表框架，其核心思想是在编译阶段将组件代码转换为直接操作 DOM 的原生JavaScript代码，不需要在运行时维护虚拟DOM树和执行DIFF算法，实现了 "零运行时" 开销。Svelte的编译器会对组件的模板进行静态分析，识别出其中的动态部分，并且生成专门的更新代码。这一步看起来和Vue3的优化方式很像。而当组件的状态发生变化时，直接执行对应的更新代码来操作真实 DOM，避免了虚拟 DOM 的创建、比较和转换过程。

// 一个计数器
<script>
  let count = 0;
  function increment() {
    count += 1;
  }
</script>
<button on:click={increment}>
  点击了 {count} 次
</button>

// Svelte编译以后
function create_fragment(ctx) {
  let button;
  let t0;
  let t1;
  let t2;
  return {
    c() {
      button = element("button");
      t0 = text("点击了 ");
      t1 = text(/*count*/ ctx[0]);
      t2 = text(" 次");
      button.addEventListener("click", /*increment*/ ctx[1]);
    },
    m(target, anchor) {
      insert(target, button, anchor);
      append(button, t0);
      append(button, t1);
      append(button, t2);
    },
    p(ctx, [dirty]) {
      if (dirty & /*count*/ 1) set_data(t1, /*count*/ ctx[0]);
    },
    i: noop,
    o: noop,
    d(detach) {
      if (detach) detach(button);
      button.removeEventListener("click", /*increment*/ ctx[1]);
    }
  };
}
function instance($$self, $$props, $$invalidate) {
  let count = 0;
  function increment() {
    $$invalidate(0, count += 1);
  }
  return [count, increment];
}

在编译后的代码里，C、P、M、D四个函数分别代表create、mount、patch和detach，类似于Vue的生命周期函数。P函数专门处理状态更新，当count发生变化时，只会执行set_data(t1, count)来更新按钮中的文本，操作非常直接高效。

Vue 3.6 Vapor Mode

开头提到的Vapor Mode另一种编译时优化的解决方案，它来于虚拟DOM，身上还有故人的影子。它的核心优化点在于：

1. 动态节点精准追踪 ：编译器在编译阶段标记所有动态节点和动态属性，生成对应的更新函数，避免运行时的 Diff 遍历。例如一个包含100个节点但只有1个动态文本的组件，Vapor Mode只会生成针对该动态文本的更新逻辑。
2. 响应式 粒度细化：将组件的响应式数据与对应的DOM更新函数直接绑定，当数据变化时，直接触发对应的更新函数，无需通过虚拟DOM树的递归更新。
3. DOM 操作批处理：编译器会分析模板中的DOM操作顺序，将可以合并的操作批量处理，减少浏览器重排重绘次数。

Solidjs

Solidjs 结合了虚拟DOM的声明式开发体验和编译时优化的性能优势，其核心是细粒度的响应式系统与编译时分析的结合。Solidjs在编译阶段会将组件转换为一系列响应式变量和DOM操作函数，每个动态绑定都会创建独立的响应式依赖。当数据变化时，只会触发依赖该数据的DOM操作，实现了比虚拟DOM更精准的更新。

总结

作为前端开发的重要里程碑，虚拟DOM的核心问题，本质上是开发效率 与运行时性能之间的平衡和博弈。

虚拟DOM的核心价值是通过抽象层屏蔽了原生DOM的复杂性，提供了声明式编程范式和组件化思想，让开发者可以专注于数据逻辑而非DOM操作细节，大幅降低了复杂UI的开发难度。为了实现这一价值，虚拟DOM通过DIFF算法减少不必要的DOM操作，提高了性能。但这种优化是有成本的------虚拟DOM的创建、DIFF比较等过程本身会产生运行时开销。

因此，虚拟 DOM 的设计始终在提升开发效率 和控制性能损耗之间寻找平衡点，React的Fiber架构、Vue的编译时优化、Svelte的零运行时方案，本质上都是对这一平衡关系的持续探索和优化。未来的前端框架更可能走向 "混合模式"------ 在编译时尽可能提取静态信息生成高效代码，同时保留虚拟 DOM 处理动态场景的能力。

从技术演进的角度看，虚拟DOM的兴衰印证了计算机科学的一个核心规律：

没有银弹式的完美解决方案，技术的价值在于解决特定历史阶段的核心问题。 ------Steve McConnell

当新的问题出现时，要么对现有技术进行革新，要么诞生新的技术范式------我想这正是前端技术保持活力的根源。