虚拟DOM这个概念对React开发者来说算是老朋友了但真被问到“它在React的一层层抽象里到底站在哪个位置”时很多人会突然卡住。我见过不少写了两年React的同事能把Diff算法、Fiber架构背得滚瓜烂熟但真让他在一张架构图上标出虚拟DOM的位置还是会犹豫半天JSX和React元素之间组件和真实DOM之间还是就是Fiber树本身这不是基础差而是虚拟DOM在React生态里本来就不是一个可以指着源码说“这就是”的类或文件它更像是对一套机制的总称。想把它定位准唯一靠谱的办法是把React“从代码到页面”的完整链路拆开看它夹在哪些抽象之间扮演什么角色。这篇文章我就按照分层的方式来拆从浏览器底层的真实DOM一路拆到React上层的JSX语法找到虚拟DOM的精确坐标再聊聊它和Fiber、React元素、Shadow DOM这些容易混淆的概念到底什么关系。无论你是在准备React面试还是在团队里被虚拟DOM绕晕了很久这篇文章应该能帮你把这层窗户纸捅破。1. 把抽象栈拆开虚拟DOM到底在哪一层1.1 从浏览器渲染到React渲染中间隔了几层先把底层的浏览器机制摆出来。浏览器里最终显示内容靠的是真实DOM这是一棵由浏览器维护的树形结构DOM节点有类型、属性、子节点也附带样式计算、布局和绘制等复杂流程。浏览器对外暴露的DOM API本质上是一些命令式的方法document.createElement、parent.appendChild、el.setAttribute你调用一次浏览器就执行一次对应的变更这是第一层。在这层之上前端框架做的事情不是消灭DOM操作而是把“操作DOM”这件事封装起来。React出现以后开发者日常写的是组件、状态、JSX到运行时会经历一次转换最终还是要落到对DOM API的调用上。这个转换过程不是一步完成的中间隔着好几层抽象。如果画一条从下到上的栈大概是这样最底层浏览器真实DOM负责布局、绘制、事件等真正渲染工作。往上一层DOM API是浏览器对外暴露的命令式操作接口。再往上一层React的渲染器层比如react-dom这个包负责在时机合适时把这些命令发送给浏览器。再往上一层React的协调层负责比较新旧两次UI描述算出需要更新什么。再往上一层React元素和组件树是开发者用React描述出的UI形态。最上层JSX语法让开发者可以用类似HTML的写法来描述UI它本身只是语法糖。虚拟DOM的位置就在协调层它是协调层处理的核心数据结构同时也是组件树和渲染器之间的中间产物。说白点它是一棵用JavaScript对象模拟的、运行在内存里的“UI快照”在React需要知道界面该怎么变化时这棵树就是计算的新旧参照物。1.2 虚拟DOM和JSX、React元素不是同一个东西很多人把JSX直接等同于虚拟DOM这是最常见的误区。JSX只是语法糖它本质上是React.createElement的调用。你写const element div classNameboxHello/div编译之后其实是const element React.createElement(div, { className: box }, Hello)createElement执行完返回的是一个普通JavaScript对象叫做React元素React Element。这个对象的结构大概长这样{ type: div, props: { className: box, children: Hello }, key: null, ref: null, // 其他内部字段 }所以链路很清楚JSX是代码层的抽象React元素是单次render调用产生的对象。那虚拟DOM在哪当一次render从根组件开始把组件树整体执行一遍产出了一大批React元素这些元素按照组件层级关系组织成了一棵树这棵树才是我们通常说的虚拟DOM。可以这么理解JSX描述的是“你希望界面长什么样”React元素记录了“某一次渲染时界面该长什么样”虚拟DOM则是这些记录按层级结构拼成的整体快照。真实DOM是浏览器的最终输出虚拟DOM则是React在JavaScript世界里构建的“平行世界”两边通过协调过程保持同步。2. 一条渲染链路看清虚拟DOM的定位与职责2.1 初次挂载时虚拟DOM是怎么被“顶”上来的要真正定位虚拟DOM最好跟着一次渲染流程走一遍。第一次页面加载时React要做的事是从根组件开始把整棵组件树渲染出来。比如这段代码function App() { return ( div classNameapp Header / Content / /div ) } const root createRoot(document.getElementById(root)) root.render(App /)React执行root.render后会调用App这个函数组件拿到它返回的React元素树。当组件里的子组件Header、Content也是函数组件时React会继续深入把每个组件都执行一遍直到整棵树全部变成原生标签节点div、span、p这类。这时React得到的就是一棵完整、纯粹由React元素组成的树这就是虚拟DOM树的初始形态。拿到这棵树以后React并不会马上直接把它塞给浏览器。它会先在内存中用这棵树构建对应的Fiber节点树然后再通知react-dom这个渲染器说“我现在有一棵完整的UI描述树你按照这个描述去真实DOM里创建节点吧”。渲染器接到命令才真正调用document.createElement把节点一个个创建并挂载到页面上。这里有个容易被忽略的重点组件函数执行时React元素对象会重新创建同样组件的render也是一个全新的过程。要建立虚拟DOM并非像读取缓存一样简单“每次状态更新都重新走一遍render”就是React工作方式的关键。2.2 更新时虚拟DOM是Diff的输入和结果的产出页面第一次挂载之后后续遇到状态更新整套流程会再次触发。重点来了React拿什么做比较状态更新时React会重新执行发生变化的组件函数产生一棵新的React元素树也就是一份新的虚拟DOM。与此同时React还保留着上一次渲染时生成的Fiber树里面记录了每个节点对应真实DOM的信息。接下来进入协调阶段React将新旧两棵树的节点逐一对比找出哪些节点需要创建、更新、移动或删除然后只针对这些变化生成对应的DOM操作命令最后交给浏览器执行。这个新旧对比的过程就是大家常说的Diff算法。React实现Diff算法时做了一些聪明的取舍比如只对同层节点进行比较不会跨层级递归比较比如只比较类型相同的节点比如用key属性来识别列表中的节点身份。这些优化都指向同一个目标把本来需要遍历整棵树的O(n^3)问题降到接近O(n)的复杂度。所以准确地说虚拟DOM在这个阶段既是Diff的输入新的React元素树也是Diff能高效工作的前提。没有虚拟DOM这份可复制的内存快照React就没有办法在不直接操作浏览器的情况下“事先计算”改哪些地方。这也是虚拟DOM在抽象链中最核心的价值让“计算UI变化”和“实际修改UI”这两个过程彻底解耦。2.3 key属性才是虚拟DOM定位中最考验功底的部分聊虚拟DOM定位不能不提key。key这个属性看起来不起眼但它在Diff过程中扮演的角色决定了列表能否高效更新、组件状态会不会被串。比如下面这个例子const items [A, B, C] return ( ul {items.map((item) ( li key{item}{item}/li ))} /ul )当列表变成[C, B, A]时如果没有keyReact只能按照索引位置依次比较发现第一个位置由A变成C第二个位置由B变成B第三个位置由C变成A于是它认为需要更新两个节点的内容。但如果加上了稳定的keyReact能直接通过key识别出三个节点原本都是谁它就知道A动了、B没动、C动了节点的位置发生了变化但没有内容变更。这样React可以复用现有的DOM节点只调整它们的位置不做无谓的内容更新。这个区别在工作量上看起来差不多但如果在列表项里维护了组件内部状态情况就完全不同了。没有key或key用了数组索引一旦列表头部插入了新项后续所有项的索引都变了React会认为每个位置上的节点身份变了原本存在某组件里的输入框内容、滚动位置、选中状态就可能被错误地复用到另一个组件上造成状态串位。实际开发中我见过不少线上问题最后排查下来都和处理key的方式有关。用数组索引做key不是绝对不能用比如列表数据不会做插入、删除、重排操作只是静态展示那索引key是可以接受的。但只要列表顺序可能变化、数据可能从中间插入删除就必须用数据本身具备唯一性标识的字段做key。key是虚拟DOM在列表场景下用来“认人”的身份证它定位的不只是节点在树里的位置更是这个节点在整个更新周期里的身份延续。3. Fiber架构下虚拟DOM是否被取代了3.1 现代React里Fiber节点到底算什么React 16做了一次大重构引入Fiber架构。很多人的疑问是既然已经有Fiber了虚拟DOM是不是过时了或者Fiber就是虚拟DOM答案要从两个概念的分工来看。虚拟DOM是React元素组成的树它描述的是“UI应该长什么样”是一种纯数据形式的快照不可变每次render都会重新生成。Fiber则是一棵独立的工作树每个Fiber节点上面挂载了比React元素多得多的信息组件类型、props、state、副作用标记、指向父节点和子节点的指针、指向兄弟节点的指针、优先级信息以及对应的真实DOM节点引用。可以这样理解虚拟DOM像是一份设计图纸Fiber树像是把图纸拆解成可执行任务清单的工作流。React拿到设计图纸后会把它转换成一棵Fiber树然后在Fiber树的节点上完成Diff计算、优先级调度、副作用收集等工作。Fiber节点真正常态存在于内存中而且随着更新不断复用虚拟DOM中的React元素则更像是每次render的临时产物。所以Fiber不是虚拟DOM的替代品而是专门为协调工作而生的可中断任务载体。React 16之前协调过程是一口气递归完成的一旦开始就不能被打断遇到复杂更新很容易阻塞主线程。Fiber架构把每个节点拆成小的执行单元配合优先级调度让React可以在处理一半时被打断先处理更紧急的任务之后再回来继续。这层能力的底层数据结构是Fiber但Diff时参照的“上一次长什么样”和“这一次长什么样”仍然依赖虚拟DOM提供的信息。3.2 双缓存机制让你在调试时更容易定位Fiber架构里还有一套很有意思的双缓存机制也是定位虚拟DOM时绕不开的细节。React在内存中同时维护两棵Fiber树一棵是current树对应当前页面上已经渲染并提交给真实DOM的UI另一棵是workInProgress树是在后台基于最新render结果构建的新树。构建workInProgress树时React会尽量复用current树中已有的Fiber节点而不是全部重建。当所有更新计算完成workInProgress树这棵“备胎”变成了最新UI的完整描述React会进行一次切换把workInProgress树变成新的current树提交阶段对应的DOM操作也在这时一次性发给浏览器。这套双缓冲机制的来源其实不在前端图形学里的双缓冲就是先把新画面画在后台缓冲再整体切换到前台显示避免出现只画了一半的撕裂画面。React借鉴这套思路让用户永远看不到中间状态不一致的UI快照。从定位角度看虚拟DOM相关的心智模型到这里就会升级为两棵树一棵是已显示的一棵是在后台更新中的你调试的时候可以通过React DevTools判断当前屏幕对应的是哪棵树。4. 在层层抽象中保留虚拟DOM这一层的理由4.1 从声明式编程到跨端能力的统一模型现在可以回答那个更能代表虚拟DOM本质的问题了为什么不直接操作DOM非要中间加一层虚拟DOM核心原因在于Web前端开发的痛点已经从“怎么把元素建出来”变成了“怎么管理大量状态和视图之间的同步”。直接操作真实DOM是命令式思路你要手动告诉浏览器每一步做什么代码量一大状态关系一复杂很容易漏掉某个更新路径。虚拟DOM提供的声明式思路让开发者只需要描述“状态应该对应什么UI”剩下“怎么从旧UI变到新UI”的工作交给框架统一处理。这一层抽象带来的另一个红利是跨端能力。虚拟DOM本身不依赖浏览器它只是一棵JavaScript对象树真正消费这棵树的renderer可以替换。react-dom把虚拟DOM转成浏览器DOM操作React Native则把它转成iOS和Android的原生组件树react-three-fiber把它转成Three.js的场景对象react-pdf甚至能把它转成PDF文档元素。也就是说开发者的心智模型只需要学React一套UI描述本身可以跑在完全不同的宿主上。虚拟DOM作为中间表示层让这种跨端复用成为可能。4.2 性能不是唯一的理由甚至不是最主要的理由每当谈到虚拟DOM一定避不开那个经典争论虚拟DOM真的比真实DOM操作快吗我的看法是这个问题如果问得绝对很容易踩坑。虚拟DOM不保证在任何场景下都比手动操作DOM快轻量页面上多一层比较计算和对象创建反而可能有额外开销。但它解决的是另一种问题一个大型复杂应用靠人力去精确追踪每个状态变化对应的DOM操作几乎不可能保证不出错。虚拟DOM的性能优势在于把复杂度集中到算法层面通过批量更新、Diff优化、任务调度这些机制在绝大多数情况下避免无谓的DOM操作同时保证开发效率和可维护性上限。换句话说虚拟DOM不是用来追求“极限最快”的它追求的是高效、可预测和跨环境。真要做极致性能优化React本身还提供了跳过Diff的memo、useMemo、useCallback手动指定“这个组件这次不用重新渲染”。把这些机制组合起来虚拟DOM的性能问题才有完整答案。5. 搞清楚这些面试和实战才算过关5.1 虚拟DOM、Shadow DOM、真实DOM一次辨清我经常会碰到有人把虚拟DOM和Shadow DOM混在一起聊虽然它们都带个DOM但完全是两个维度的东西。真实DOM是浏览器渲染内容的树形数据结构是页面内容的实际存在形式。Shadow DOM则是浏览器原生提供的一种封装机制让组件可以把内部的DOM结构和样式隔离起来外界的选择器和样式表不能轻易影响它内部的东西比如video元素内部的播放控件就是Shadow DOM的典型应用。虚拟DOM和这两个都不一样。它不在浏览器内部而是React在JavaScript运行时里自己维护的一份内存数据用来描述UI长什么样。它的目标是作为中间层让“描述UI”和“操作宿主组件”解耦。三者对比一下概念存在位置主要作用谁在使用真实DOM浏览器内部页面内容的实际载体负责布局、渲染、事件浏览器环境Shadow DOM浏览器内部对DOM子树做样式和行为隔离Web Components虚拟DOMJavaScript运行时抽象描述UI支撑Diff计算和跨端渲染React、Vue等框架面试里被问到“什么是虚拟DOM”时你可以不只说“它是一个描述页面的JS对象”还可以补充“它和真实DOM的关系类似于设计稿和成品实物的关系React通过它在内存里做UI变更推算最终再通知浏览器执行具体操作这也是React能跨平台渲染的基础之一”。5.2 高频面试题和常见误区这几年面试React岗位虚拟DOM相关问题几乎必考但不少候选人的理解还停留在“虚拟DOM比真实DOM快”这种单点结论上漏洞一追问就出来了。我把几个高频问题和常见误区整理一下。问题一React的虚拟DOM数据结构长什么样虚拟DOM树由React元素组织而成。每个React元素是一个普通对象包含type、props、key、ref等字段。组件树渲染完成后这些元素会按父子关系形成一棵树。更偏向底层实现的话React在协调阶段还会为每个元素创建对应的Fiber节点Fiber节点通过child、sibling、return指针形成链表结构这也让协调过程可以被打断、分片执行。问题二为什么列表渲染时key不建议用index因为key的作用是标识节点在整棵树中的稳定身份。用index做key时一旦列表发生插入、删除、重排React会按位置对新旧节点做匹配导致节点身份错乱组件状态可能被错误复用甚至出现渲染错误。稳定唯一的数据字段才适合做key。问题三虚拟DOM一定比直接操作真DOM快吗不一定。手写最优DOM操作肯定可以比任何框架都快但那是在“知道每次具体该改哪个节点”的理想前提下。虚拟DOM的价值在于当UI状态复杂到人无法预判所有变化时仍然能通过算法保证整体效率不至于失控。所以准确说法是虚拟DOM让React在不需要手动优化的情况下也能获得大部分场景下足够好的性能。问题四React更新是“组件一变就立刻操作DOM”吗不是。React会把一次更新对应的所有变化收集起来经过协调计算后统一进入提交阶段最终一次性提交给浏览器。这也是为什么连续修改状态多次React只触发一次真正的DOM更新。频繁读取DOM布局属性的操作如果写在更新流程中间很容易破坏这种批处理造成额外的性能损耗。5.3 一个实战里特别容易踩的坑我在项目里踩过一个大坑某列表组件在滚动加载时频繁更新但页面滚动越来越卡。当时我先想到的是把列表项用memo包起来优化了半天效果不明显。后来用React DevTools的Profiler录了一段性能分析才发现问题出在列表顶部一个紧跟滚动状态的组件每次都在生成新的JSX对象间接导致列表数据引用变化整个列表的Diff白算了。这类问题其实和虚拟DOM的定位直接相关。组件的render函数重新执行返回的React元素对象就会全部重建就算它们对应的UI最终没有变化协调器也要判断一次。要避免这种浪费关键不是去优化Diff本身而是从源头控制哪些组件需要重新执行memo记忆组件、useMemo稳定数据引用、状态拆分到位这些手段配合起来才能让虚拟DOM那套比较机制真正只处理必要的更新。6. 说点我自己的体会做前端这些年我对虚拟DOM的态度经历了一个从崇拜到平常心的过程。刚入行那会觉得这个东西简直神奇后来随着项目规模变大、性能问题变多又开始怀疑它是不是太笨重。到现在我更愿意把它看作一个阶段性的架构答案它牺牲了一部分极致性能换来了React跨端能力和开发体验的统一也让前端从“手写DOM操作”这个泥潭里彻底抽身出来。如果问我给学React的人什么建议我会说不要只背“虚拟DOM是什么”的结论最好自己动手在代码里打印一下React.createElement的返回值再用React DevTools观察一次状态更新前后的组件树变化。你很快会发现所谓虚拟DOM不是玄学就是一份再普通不过的JavaScript对象真正的难点在于理解框架如何在恰当的时间消费这份对象、调度更新、提交变化。把这些串起来你对React的理解就不只是停留在“会用”的层面了。