北京
“React快，是因为它用了虚拟DOM。”这句话你大概听过很多次。听起来挺合理：浏览器的DOM被说得很贵，React用虚拟DOM，所以自然得出一个结论——虚拟DOM比真实DOM快。但这个结论并不准确。
虚拟DOM并不是天生就比真实DOM快。如果你明确知道哪个DOM元素需要改，直接更新DOM有时反而比走React那套渲染和协调流程更快。那React为什么还要用虚拟DOM？它到底在解决什么问题？如果虚拟DOM不是简单的“更快的DOM”，它又有什么用？
先搞清楚真实DOM是什么
DOM是文档对象模型。浏览器解析HTML时，会在内存里把文档表示成一棵树。比如一个div里有一个h1和一个button，结构上就是div下面挂着h1和button，h1里是“Hello”，button里是“Click me”。这就是真实DOM，是浏览器显示网页时实际操作的文档结构。
JavaScript可以直接改它。一句document.getElementById("title").textContent = "Hello, Nayan"，就直接改了真实的DOM节点。这里有个关键点：直接操作DOM本身并不坏，也不一定慢。如果你清楚要改什么，直接更新DOM可以非常高效。比如element.textContent = "Updated"，几乎没有抽象层，流程就是“什么变了→哪个元素变了→更新那个元素”。
“真实DOM=慢”这个说法太简单了
DOM本身未必是问题。浏览器在DOM变化之后，往往还要做额外的工作。一个简化的渲染管线是这样的：DOM变化之后，依次是样式计算、布局、绘制、合成，最后才变成屏幕上的像素。工作量很大程度上取决于改了什么。
改一个小元素的文字可能比较便宜；但如果改的属性影响页面大范围的布局，那要做的工作就多得多。所以开发者说“DOM操作很贵”时，通常指的是频繁或者管理不当的DOM变化会带来额外的渲染开销，而不是说DOM这个结构本身慢。
把“真实DOM=慢”当成绝对结论，会漏掉真正的成本来源。虚拟DOM的价值不在“比真实DOM快”这个伪命题上，而在于它提供了一种可预测的更新方式：先把变化算出来，再批量去碰真实DOM，避免频繁、零散地触发浏览器那套昂贵的后续流程。理解这一点，比记住一句口号有用得多。
特别声明：以上内容(如有图片或视频亦包括在内)为自媒体平台“网易号”用户上传并发布，本平台仅提供信息存储服务。
Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.
