虚拟DOM：虚拟DOM和实际DOM有何不同|浏览器篇

虚拟 DOM 是最近非常火的技术，两大著名前端框架 React 和 Vue 都使用了虚拟 DOM，所以我觉得非常有必要结合浏览器的工作机制对虚拟 DOM 进行一次分析。当然了，React 和 Vue 框架本身所蕴含的知识点非常多，而且也不是我们专栏的重点，所以在这里我们还是把重心聚焦在虚拟 DOM 上。

在本文我们会先聊聊 DOM 的一些缺陷，然后在此基础上介绍虚拟 DOM 是如何解决这些缺陷的，最后再站在双缓存和 MVC 的视角来聊聊虚拟 DOM。理解了这些会让你对目前的前端框架有一个更加底层的认识，这也有助于你更好地理解这些前端框架。

原理拆解： 真实 DOM 是浏览器维护的宿主对象，节点变化可能使样式计算、布局、绘制或合成失效；业务代码若在一次更新中反复读取布局信息并写入样式，还可能迫使浏览器提前完成布局。虚拟 DOM 则是 JavaScript 中对界面结构的描述。状态变化后，框架生成新的描述，与旧描述比较，再把必要变更集中提交给真实 DOM。它减少的是缺乏组织的宿主操作，并不意味着比较过程或每次更新都没有成本。

具体实现： 假设列表只把第二项文本从 B 改成 C，新的虚拟树可以通过节点类型、属性和子节点关系定位差异，最终只设置对应文本节点。列表插入、删除或重排时，稳定的 key 用于表达节点身份，使框架能够复用正确的真实节点；使用数组下标作为会变化列表的 key，可能把输入框状态复用到错误条目。双缓存视角下，新旧两棵描述树分别承担当前画面和下一画面的角色；MVC 视角下，它位于状态与视图提交之间，把声明式结果转换为命令式修改。

边界与反例： 虚拟 DOM 不是天然快于所有手写 DOM。一个已知位置的单次文本修改，直接更新真实节点通常路径更短；超大列表的全量建树与比较也会消耗 CPU 和内存。性能收益取决于更新范围、调度策略、节点身份以及最终触发的渲染阶段，不能只统计 DOM API 调用次数。不同版本的 React、Vue 在节点表示、调度和优化提示上存在差异，不宜把某一实现当成统一定义。

工程验证： 应使用浏览器性能面板记录脚本执行、样式计算、布局、绘制和长任务，再比较相同交互的提交次数与帧耗时。测试列表时同时检查稳定 key、输入状态和节点复用；出现卡顿时区分是虚拟树计算、真实 DOM 提交，还是布局与绘制成本。只有测量真实用户路径，才能判断优化应落在减少渲染、拆分更新还是缩小可见数据量。

通过前面一系列文章的学习，你对 DOM 的生成过程应该已经有了比较深刻的理解，并且也知道了通过 JavaScript 操纵 DOM 是会影响到整个渲染流水线的。另外，DOM 还提供了一组 JavaScript 接口用来遍历或者修改节点，这套接口包含了 getElementById、removeChild、appendChild 等方法。

比如，我们可以调用document.body.appendChild(node)往 body 节点上添加一个元素，调用该 API 之后会引发一系列的连锁反应。首先渲染引擎会将 node 节点添加到 body 节点之上，然后触发样式计算、布局、绘制、栅格化、合成等任务，我们把这一过程称为重排。除了重排之外，还有可能引起重绘或者合成操作，形象地理解就是“牵一发而动全身”。另外，对于 DOM 的不当操作还有可能引发强制同步布局和布局抖动的问题，这些操作都会大大降低渲染效率。因此，对于 DOM 的操作我们时刻都需要非常小心谨慎。

当然，对于简单的页面来说，其 DOM 结构还是比较简单的，所以以上这些操作 DOM 的问题并不会对用户体验产生太多影响。但是对于一些复杂的页面或者目前使用非常多的单页应用来说，其 DOM 结构是非常复杂的，而且还需要不断地去修改 DOM 树，每次操作 DOM 渲染引擎都需要进行重排、重绘或者合成等操作，因为 DOM 结构复杂，所生成的页面结构也会很复杂，对于这些复杂的页面，执行一次重排或者重绘操作都是非常耗时的，这就给我们带来了真正的性能问题。

所以我们需要有一种方式来减少 JavaScript 对 DOM 的操作，这时候虚拟 DOM 就上场了