你还在用这个回答？

 因为操作真实DOM效率低，而虚拟DOM是普通对象，效率更高

这句话中每一段话都没错，但是连起来就有问题了，来看图

就拿Vue做例子，在初始化时会生成一些数据，然后它会根据数据去生成虚拟DOM 普通对象，最后再根据虚拟DOM生成真实DOM。

当数据发生改变时，它也会全量生成虚拟DOM，然后用新生成的虚拟DOM和旧的虚拟DOM作对比，找出差异，然后精确的完成真实DOM的更新。

### 再来看看JS🤞

JS在初始化时生成数据，然后根据数据生成真实DOM

当数据变化了，找出对应的真实DOM更改它，就完事了。

这样一作比较，明显是JS的效率更高呀，虚拟DOM反而降低了效率，那既然这样为什么我们不直接使用JS操作DOM ?还要是用虚拟DOM？

两大原因

第一个原因

像Vue这种框架，它是一个通用的框架，而它们的框架设计的核心理念就是把这个数据与这个界面进行对应，当数据变化的时候，要能够正确的去渲染界面。这样就产生了问题，数据和界面它是如何对应的？这样就有些复杂了，因为一个数据可以在不同元素里重复使用，而一个元素里面，它又可能用到多个数据，对应关系是极其复杂的，而Vue作为通用框架，它是很难预知数据和界面之间到底是如何对应的，所以它直接采取了一个简单粗暴的方法-->只要数据一变，不管三七二十一，我界面全部重新生成一次，要是使用JS直接操作DOM的方法的话，那它的代价就非常昂贵了。因为每个元素都要重新生成一遍。所以为了减少对真实DOM的操作，它不得不引入虚拟DOM，就是数据发生变化之后，由于我不知道界面上哪个地方需要更新，所以说我既然要全量生成，我就不去全量生成真实DOM，而去全量生成虚拟DOM，然后通过跟之前的虚拟DOM来进行对比，找到那个有差异的地方，然后改动它对应的真实DOM，这其实就是Vue不得而为之的挽救方式，因为它很难做到把数据和最终的界面一一对应，才不得不去引入虚拟DOM，来减少对真实DOM进行无意义的改动。

第二个原因

“抽象” 为什么呢？因为像Vue、React这些框架在设计的时候，并没有把自己想象成一个页面级别的应用框架,而是把自己定位成一个UI库(user interface)，表示用户界面，那么用户界面就一定是网页吗？显然不是，它可以是移动端，可以是桌面应用程序。不同的平台差异是很大的，而我们平常说的DOM通常是值页面应用，页面里面才有DOM，那小程序呢？移动端app呢？桌面应用呢？哪来的DOM ？所以说它是为了消除平台之间的差异，于是抽象了一个UI的表达方式，它使用了一个普通对象(虚拟DOM) 来表达UI界面，然后根据不同的平台(移动端、桌面程序或者是页面)，去具体生成真实的界面，这就是建立了一个抽象层。

总结🤳

• 虚拟DOM不是为了提升效率的，而是为了抹平各端的差异。
• 虚拟DOM对于Web端而言，减少开发者操作DOM的心智成本