Es gibt ein Konzept des virtuellen DOM in React
Der Unterschied zur nativen DOM-Operation besteht darin, dass JS verwendet wird, um ein virtuelles DOM ähnlich einem Vermittler zu generieren.
Dies ist ein DOM, das mit JS implementiert wird. Es zeichnet einige Datensätze davor und danach auf Führen Sie beim Rendern die Änderung durch und führen Sie dann erneut ein lokales Rendern differenzierter Teile durch. Dies vermeidet das Rendern der gesamten Seite? Die native Operation von DOM besteht also darin, die gesamte Seite zu rendern? Ich sehe viele Beispiele im Internet, die besagen, dass innerHTML bei jeder Änderung direkt zurückgesetzt wird. Wenn bei diesem Vorgang eine große Datenmenge verwendet wird, wird es GG sein, ha? Virtual DOM zeichnet Änderungen auf, verwendet dann seinen Diff-Algorithmus zur Optimierung und rendert schließlich lokal dort, wo Änderungen vorliegen. Ich kann also mit Native nicht den gleichen Effekt erzielen? Kann ich die Änderungen nicht auch durch Vergleich finden und dann den Diff-Algorithmus verwenden, um innerHTML an der angegebenen Stelle zu ändern? Wird diese Effizienz schlechter sein als bei Virtual Dom? Lösen
我的理解是你可以做到比React快，如果你能做到两点：
Avoid unnecessary re-render.
Have a better diff algorithm!
具体可以看
stackoverflow上virtual dom作者的回答。是这样的:
首先, 虚拟dom并没有比直接原生操作更快, 所谓"快"是有条件的
比如点赞, 数字+1, 直接操作dom会更快.
如果你能自己捋请规则, 每回手动操作dom的时候, 都只改动应该改变的, 那dom操作永远比虚拟dom快.
但如果你的改动勾连的地方很多, 而且要保持状态, 那虚拟dom的自动diff无疑会让你省更多心.
比如一个列表, 列表项有点赞等状态, 回复数量等信息, 有动态新增, 有动态加载, 这时候你要直接操作dom会很繁琐.
虚拟dom的核心在于diff, 它自动帮你计算那些应该调整, 然后只修改该修改的区域, 省下的不是运行速度这种小速度, 而是开发速度/维护速度/逻辑简练程度等"总体速度"
当然, 虚拟dom也有槽点, 这里就不展开了
如果耗费大量精力去优化每一个页面的每一种 DOM 变化，你肯定是比自动化的 virtual DOM 快的；
问题是在通常情况下你不会去这样做。
所以在大部分情况下，vitrual DOM 能在速度更快的条件下，提供更强的能力（例如把控件渲染到 canvas 上）。
visual DOM并不会比你直接操作DOM来的快（写的代码足够好的前提下），它的出现是因为React re-render all的机制。即对于React而言，任何一点的变化都需要重新渲染整个应用，如果是真实DOM的话，这样的性能是不能接受的。
具体可以看看尤大的回答
(用VDOM diff来选择性地更新DOM) (一般) 比 (每次重建DOM) 快
diff算法为了降低时间复杂度一般会牺牲品质，不保证能给出最小diff。那么应该可以构造几个VDOM 使得diff结果就是重建DOM，这种情况下VDOM可能更慢。